On Wed, Aug 20, 2003 at 04:24:19PM +0200, Dominic Spratley wrote:
The RIPE NCC is pleased to announce the release of new request forms for IPv4, IPv6 and AS requests.
Uhm, can someone point me to the discussion and decision finding process leading to these rather radical changes to especially the PI request? I must have missed those. In detail, I'm somewhat _shocked_ about things like: - "why-pi:" This is a new requirement. Formerly, you didn't have to justify that. In one example, "Also security reasons means independence is required." is used to justify PI. Can anyone explain what "PA or PI" has anything to do with security? - "Respecting the goal of address space conservation, it is not acceptable to request a larger number of IPs than are needed for routing or network administration." Any LIR is allowed to do so by granting them an allocation. For LIRs, address space conservation is less of an issue? _Especially_ enterprise LANs/WANs can have some very complicated routing situations requiring sensible subnetting. - [EQUIPMENT DESCRIPTION] This requirement _can't_ be meant serious. We're not on April 1st, are we? The silliness of such information requirement was already recognized within the IPv6 allocation realm, so why introducing it now again for IPv4? Further, the term "peer" is used in a very unclear way in the ASN request form and the supporting notes. Formerly, one uplink and one peer (commercial term) were enough to justify an ASN, as this constitutes a "unique routing policy". The ASN request form allows this interpretation of "peering partners" with "peering" in the technical sense. BUT the supporting notes specifically mention the requirement for two peers to "ensure that the organisation is multihomed". For me, multihoming means to have at least two _upstreams_. This would be a more stricter policy than before. What was the real intention behind these phrases? These documents should be very specific in the usage of "peer". It might be interpreted technically or commercially, each implying different constraints. I suggest changing the wording from "peer" to "upstream" in order to avoid ambiguities. Regards, Daniel