[ncc-services-wg] Request Forms: updated and available on LIR Portal

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