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

Hi Daniel,

I hope I can clarify some of your points below:

At 03:37 AM 8/21/2003 +0200, Daniel Roesen wrote:
>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.

We hope that the new forms will improve services to our members by only
asking for relevant information relating to the evaluation of a request.  By
trying to be explicit about what information Hostmasters need, we aim
to reduce the number of E-mails asking for further information and therefore
reduce the overall time it takes for our members to receive their resources.
We considered this to be an action on us from RIPE 38:

"< 38.2 NCC Implement changes to the form while taking into account the
comments from the WG >"

http://www.ripe.net/ripe/wg/lir/lir-actions.html

>In detail, I'm somewhat _shocked_ about things like:
>
>- "why-pi:"
>
>     This is a new requirement. Formerly, you didn't have to justify
>     that.

You raise a good point which we need to clarify.  We are not asking members
to justify to us why they need PI address space.  However, what we find is
that a number of LIR's misunderstand the difference between PA and PI
address space and that time is often lost in trying to establish if this is
the actual type of resource the LIR wants.  By asking them to explain
why they need PI address space rather than PA address space it helps resolve
this issue and the request is processed faster.

Having read through the supporting notes for PI assignment request form,
I agree with you that it is ambiguous to say the least.  We will update the
document in the next release.

>     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?

In our examples we tried to use the terms and phrases that our members
actually use in the forms that they send in to us.  Statements like the one
above are regularly seen, in conjunction with further supporting
information, in PI request forms.

>- "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.

RIPE - 127 talks about:
"Assignment criteria for both kinds of address space will be exactly
identical with regards to the amount of address space assigned, the
registration requirements, etc. This also implies that assigning PI space
prefixes longer than 24 bits is perfectly acceptable if the request does not
merit 8 bits of address space to be assigned."

http://www.ripe.net/ripe/docs/pi-pa.html

and in fact it is this particular part of the policy that sparked off the PI-TF
and is currently under discussion on the address-policy-wg mailing list.

>- [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?

This is a difficult one as it does require the LIR to do more preparation on
their side.   The less time a Hostmaster spends sending E-mails asking
for additional information, the sooner the LIR gets their requested resource.
Asking for the type of equipment used really helps the Hostmaster
understand what and why IP addresses are being requested.

>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.

Again this is a good point.   However I don't think that either term is
appropriate for all situations.  When writing these documents we used
the word peer as we wanted to emphasise it was the routing policy which
was important.

When designing these new forms we made sure that they could be updated and
amended given feedback from the community at a later date.  We appreciate
your comments and hope that we have been able to clarify at least some of
your points and address others in future releases.

Best regards

Dominic Spratley
Registration Services Manager
RIPE NCC