comments on "Revision of IPv4 policy doc"
- Date: Fri, 25 Jan 2002 15:33:23 +0100
Hi Nurani, Mirjam, Editorial team,
On Fri, Jan 11, 2002 at 01:12:39PM +0100, Nurani Nimpuno wrote:
> We wish to draw your attention to the revision of the current IPv4 policy
> document and the first draft, posted on the web in August 2001:
>
> http://www.ripe.net/rs/ipv4policy.html
Quite some time has passed :-) but here are my comments on it. The comments
are based on the original draft sent by Nurani to the list "ages ago",
and do not take into account any more recent changes and the comments
below. I see that there is overlap on a couple of points, which propably
mean that work is needed there :-)
Gert Doering
-- NetMaster
---- snip -----
Comments on the RIPE-185bis draft.
Overall comments:
* removal of sections not related to IPv4 allocation policy is a good
thing. Maybe add pointers nevertheless? References section?
* removal of "routing considerations" is tricky issue. We need a BCP
document and a clear and explicit reference to that, to help answering
the "shall I request PA or PI" question before it even appears...
* Sub-Allocations? We should re-start the discussion on *that*, and
possibly include the results into the policy document (avoiding a
re-write just after finishing it).
If we decide that we want sub-allocations, it will affect all
sections that talk about assignment hierarchy (RIR->LIR->end user).
Specific comments to some sections/wordings:
3.1 "Goals" -> "Conservation" - "to maximize the lifetime ..."
I'm not so sure I want to "maximize the lifetime" of IPv4. Maybe we
should rephrase it as "to avoid unfairly wasting a limited resource"
or something like this?
"Goals" -> "Registration"
I think it could be added that registration also helps conservation
(due to being able to see what's going on and who might be wastive).
"Definitions" - "Additional RIRs may be established in the future"
Shall we mention AfriNIC and LACNIC here, as it seems pretty sure that
they will happen?
"Definitions" -> "Allocation" -> "An LIR is not allowed to sub-allocate..."
See above :-) - this is happening, and I think we should sort this out.
4.0 "Good faith"
important point.
5.1 PA -> "... are part of a bigger block ... allocated to an LIR (or an RIR)"
I don't understand why the "(or an RIR)" part is there - when the
block is given by IANA to the RIR, it's not yet PA or PI, and as the
RIR doesn't assign PA to end users, I think this just doens't apply.
5.1.2 Documentation -> "IP address requests ... must, however, be submitted"
The "however" is a bit funy as the paragraph above doesn't clearly
state that use of the RIPE forms is *not* required. Maybe these
paragraphs should be clarified:
"The LIR can gather this information in any form it wants. To assist
in doing this, the RIPE NCC provides a set of forms [...]. If the LIR
needs to send the request to the RIPE NCC for verification or during
an audit, the documentation MUST be presented in the ''European IP
Address Space Request Form'' [URL] so it is recommended to do the
initial data gathering in the form as well."
I think a pointer to 5.3.3 would also help to clarify this.
5.1.3 Registration requirements
As far as I remember, there are special procedures in case the LIR
doesn't want to make the information about its customers public
(for confidentiality reasons, or because it's large-scale dialup, or
whatever) - does this still hold true? If yes, it should be mentioned
here.
5.1.8 Private address space
I think we should make it clear that there is NO implicit "SHOULD"
here - it is OK to say "I do not WANT to use private addresses"
to warrant PA space.
The existing text doesn't *have* a "SHOULD" - but from discussions
I had with other LIRs in the past, there was a frequent misconception
that "the RIPE hostmasters want us to urge people to use RFC space",
which isn't true, and might be worded even more clearly.
5.1.9 Static assignments - "The use of static ip address assignments ...
for dial-up customers is strongly discouraged".
I am not sure where this policy came from (it was there "all the time
I can remember back"), but I can nearly hear Wilfried speaking "where
is the difference between dial-up and DSL and radio connections regarding
IP address assignments".
I agree that for "typical end-user home usage websurf-only dial-up",
dynamic IP addresses do the job.
On the other hand, there can be dialled-on-demand connections with
server systems, firewall needs, or whatever behind them that require
the same IPs every time the connection is established (and maybe even
more than just one IP in case there's a dialup router involved).
So... maybe it's time for a round of policy clarification here?
Maybe it's only necessary to clarify what kind of assignments this
applies to - does it apply to:
* customers that have filled in a RIPE-141, have had their
request approved, are registered in the database, and just happen
to use dial-up as connection to the internet while waiting for
their leased line to be set up.
* large blocks of addresses that the LIR is trying to "allocate" to
"we will use this block for statically assigned dial-up customers".
If I remember discussions with Joao and Wilfried correctly, this
actually applies only to the second variant - but this should be made
very clear here, something like:
"If the LIR wants to make static assignments to large numbers of
end-users without registering individual assignments into the RIPE
database, as might be required for static single-IP dial-up, cable
modem usage (with fixed IPs), DSL customers (with fixed IPs), special
verification procedures apply. Talk to your friendly hostmaster."
Does this reflect current policy? (I'm not sure how much of that
is "decided-upon policy" and how much is "used-to-it procedures").
(The title of this section is definitely misleading. All assignments
are "static", at least in the sense that "assignment" has been used
so far).
5.1.12: IP address space replacement procedures
Do I read this correct that if a user comes to me and says "hey, I have
this /20 PI space, and want to swap it into a /20 PA", and I can verify
that this space is actually used to more than 50%, I can assign the /20
even if it exceeds my AW by far?
I read this between the lines, but if the AW really doesn't apply
(unless there is less than 50% usage) it might be useful to explicitely
document that.
It has interesting implications for further assignments and AW
applicability as well (like "trade-in a /22 and request another /24" -
does only the new /24 have to be validated against one-AW-per-year?).
5.2.1 - numbering typo
(there are two 5.2.1 sections)
5.2.2 - Further Allocations - "To obtain a new allocation [..] submit [..]
that includes a complete list of the assignments made [..]"
Huh? Not having applied for a new allocation recently, I can't comment
on the correctness of this statement, but it strikes me as "weird".
What kind of data does the NCC expect here?
"whois -r -T inetnum -M a.b.0.0/16" is a complete documentation - and
a bit heavy for inclusion in an e-mail. If the entries are not in the
RIPE database - tough, allocation rejected. Go home and fix your mess.
I think this should be clarified...
5.2.4 "Assignments to other providers"
I find the part about "what happens to existing assingments if such
an ISP becomes a LIR" a bit unclear. No suggestions on improvements,
though. Maybe add a part about motivation? I don't really see the
need to force end users to renumber just because their ISP became
a LIR on its own - *new* assignments is easy to understand, but what's
the gain for existing ones?
5.3.5 "Publishing LIR policy".
It's a little unclear that this actually applies primarily at LIR
establishment time (you send your application to the NCC and tell
them about your plans). Or do people actually update this information
regularily?
(Nothing has ever changed in our focus, so there wouldn't have been
any need...)
I find the whole paragraph a bit unclear as to "at which time does the
LIR have to do what?"...
5.3.8 "closure"
Hmmm. Interesting approach "you've been unwilling to pay your bill,
and we haven't been able to contact you for month, so please shut down
now and tell us about anything that you want to preserve regarding
your address space / AS numbers". I'm not sure how workable that is.
(But this is "procedures" and not all that relevant to *this*
document)
6.0 "Glossary"
"Address Space" - 123.456.789.012 is not a valid IP address (pleeez! :) )
(and we're not actually talking IPv6 here)
"Autonomous System Number" - I think the reference to EGP can be dropped
(never seen or heard about a network that still uses it)
"Conservation" - hmmm, again that reference to "maximise the lifetime",
see my comment above.
"End User" - "does not provide services to customers" - this is unclear
(he might provide *other* services just fine), maybe
"does not provide IP assignment/allocation services"?
"Internet Registry System" ... "was established some 10 years ago" ->
relative date specifications are kinda difficult in a
document that is meant to suffice for a while, no...? ;-)
Appendix I - RIPE DB - "the person object needs to reference a nic-handle"
Hmmm, I might be misunderstanding this, but shouldn't it be "the
person object is referenced from the inetnum: by its nic-handle".
"ALLOCATED UNSPECIFIED" - it should be pointed out that blocks assigned
from the IANA to the RIRs might still have this status (cf. 195/8),
but that new blocks assigned RIR->LIR will never have anything but
ALLOCATED PA.
"When heirarchical authorisation is implemented, authorisation can be
used for the creation..." - huh? What does this refer to? Normal
"mnt-lower" procedures? or "status: LIR-PARTITIONED"? Unclear.
--
Total number of prefixes smaller than registry allocations: 71770 (72395)
SpaceNet AG Mail: netmaster@localhost
Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0
80807 Muenchen Fax : +49-89-32356-299