Re: gerts mail
- Date: Sun, 03 Mar 2002 20:19:24 +0000
Dear Gert, Dear Carlos,
Thank you very much for the effort you have put into reviewing this
document and the useful comments you have made. I am sorry for the
delay in responding to your input, but I wanted to collect all
comments first. Please find my replies inserted below. Many of your
suggestions have been incorporated in the next version of the new
policy document that I will send out shortly.
* Overall comments:
*
* * removal of sections not related to IPv4 allocation policy is a good
* thing. Maybe add pointers nevertheless? References section?
*
As agreed earlier, we will separate IP addresses from ASNs. AS
Number assignment policies will be in a separate document.
We will also take out all general sections that apply to more than
just this document and are often even valid in all regions. The RIRs
are currently working on documents covering the following topics
(basically all introductory sections out of RFC2050): -
Definitions/Terms/Glossary - Internet Address Space/Allocation
Hierarchy/Internet Registry System - Goals of Public Address Space
Distribution - Policy Framework
We will then have one place where these issues are defined and
described. All other documents will contain pointers to these
definition documents. Therefore I won't respond to your comments
regarding section 3and 4, but will keep your suggestions as input for
the other documents.
* * 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...
Wouldn't this be something the RIPE Routing-WG could work on?
*
* * 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:
*
*
I won't comment on section 3 and 4 now as these sections will go out,
but we will keep your comments for the other documents.
* 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 RI
* R)"
*
*
* 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.
*
Good point. Allocations we receive from IANA are not marked as PI or
PA (even though most allocations we receive today are assumed to be
further distributed as PA, whereas PI assignments are mainly made from
old blocks). We will take the last part out of that sentence.
* 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.
*
You are right. This can be clarified a bir more. Thanks for the
suggested text.
*
* 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.
*
The assignment of up to a /30 to individual end users does not have to
be registered with customer details but can be marked as part of the
LIRs infrastructure. Also point to point links are viewed as
infrastructure. I will add this to the section.
* 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.
*
Even though the paragraph is correct as it is, I see your
point. We will try to clarify this.
* 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 regardi
* ng
* 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).
*
*
This comes from the time when dial-up was more or less the only
way for home users to connect to the Internet. The dial-up market just
started to grow and one particular ISP 'promised' every customer their
own static address when subscribing to their service.
The RIRs and other dial-up ISPs were afraid this would become popular
and agreed this policy including that particular wording (strongly
discouraged) and the special verification methods with the IANA (Jon
Postel at the time). And I think, it actually really helped to make
ISPs think twice before they assigned static addresses for dial-up.
That means it really is a "decided-upon policy".
However, I agree with your assessment that technology has evolved in
the meantime and that the wording in the current document is too
limited. We will clarify this section (including the title). Thanks
for the suggested text!
* 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?).
*
Mir: I see your point and have tried to clarify this in the new version.
* 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...
We do not ask for the entire inetnum object, but only for a list
of IP address range and end user. This helps checking for consistency
in the database. But if this is not clear we will try to clarify this
in the text.
*
*
* 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?
*
You are right, this paragraph is a bit complicated, I will try
to clarify it.
* 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?"...
*
This is in here for historic reasons and today only applies to
new LIRs. We will either clarify this or remove this section
completely as it is described in more detail in the New-LIR document.
* 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)
*
We will remove the procedural details and only keep the part that
describes policy.
* 6.0 "Glossary"
This section will go out and be published as a separate document.
*
* "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 i
* t)
*
* "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)
*
Thanks again and much fun with the next version ;-)
Mirjam Kuehne
RIPE NCC
