Comments on -- Re: comments on "Revision of IPv4 policy doc"
- Date: Sat, 26 Jan 2002 16:14:18 +0000 (WET)
On Fri, 25 Jan 2002, Gert Doering wrote:
> 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
>
Hi All,
Didnt had the time to review it from scratch, so ill pickup on Gert's
comments! (hope he doesnt mind...)
> ---- 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?
Agree.
> * 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...
Gert, have you already found the miracle solution to the multihoming
problem? ;-)
Or "Find the best ISP you can!" is still at number one? :-)
> * 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).
Yep. My opinion is: i dont want sub-allocations. Im not seeing any
advantages of having them.
I think current philosophy is good.
>
> 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?
Agree. Time will come when we will have the "Trying to discontinue the
IPv4 stack, just stick to IPv6" problem.
We dont want IPv4, we want IPv6, right?
> "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).
Agree. Also in the point it can help keep track and get back to
*really* free address space status unused space?
> "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?
Agree. Havent yet thought about why ripe, arin and apnic are RIR's and not
CIR's (Continental). Perhaps in the past reason was covering more than 1
continent, and perhaps in the future we will see RIPE and ARIN
subsetted... :-) any prospects on that?
I mean, my opinion is that RIPE is doing an wonderfull job *as is*, this
kind of idea could worsen things up a bit, no?
> "Definitions" -> "Allocation" -> "An LIR is not allowed to sub-allocate..."
>
> See above :-) - this is happening, and I think we should sort this out.
Probably, but is this the majority of cases, or a little minority?
> 4.0 "Good faith"
>
> important point.
Yep.
> 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.
Its clear to me why its not PA or PI, and i aldo can see any advantage
on a RIR having different "gives" by IANA and separate PA from PI.
Is there any name when IANA "gives" a part of the address space to a RIR?
Is it "allocatted unspecified" ?
> 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.
I think this part is somewhat fuzzy... i know that for legacy reasons
perhaps is a good idea not to enforce having all assigns by a LIR on RIPE
forms. But the best practice and the fastest common sense imply that doing
things right at the first time is best. Perhaps what this part needs is
somewhat a bigger emphasis...
> 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.
Dont know anything about this privacy thing. Have to check it soon...
Personal opinion is that confidentiality is a good thing. :-)
> 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.
I understand current policy is what you are saying, but perhaps we could
turn it better by talking about a "per situation evaluation".
> 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.
And dont we want people to use RFC space???
> 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).
Well i've already seen solutions & solutions around that...
> 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."
Im not in the commercial business, but i havent heard of nobody in my
country doing this kind of thing... usually people "agreggate" assigns on
"project" or "commercial package", no?
Perhaps im not understanding this right...
> 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?
My opinion is that this case should always have the RIR's "blessing".
Sorry for the term, im not catholic, but this is a catholic country... ;-)
> 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?).
That would seem to me the right choice... the trade-in is just a
particular case, right?
> 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...
Also agree with Gert, and im not also thinking about asking for a new
allocation in the next years... (except perhaps IPv6...) :-)
On this, perhaps the use of AS-USED tool (executed by RIPE) would do the
trick...
> 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?
Perhaps i dont understand the problem... isnt it rule number one, if you
want to be an ISP, get an AS number and an allocation???
Out of topic, i still have one problem with an university that some years
ago thought about being an ISP and got an ASN and an allocation... Now
they are on my "special cases" list, and are *always* a management
nightmare... oh, and they are also some kind of "Dead LIR" to RIPE... :-)
Didnt understand that part quite good yet...
> 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?"...
Should it exist a field anywhere at a form where a LIR candidate puts an
URL where is stated its future LIR policy???
Should this be a *requirement* or a best practice?
> 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.
No "new" response... so... total cleaning up??? i would vote for that.
one month time between events seems to me very, very short!
> (But this is "procedures" and not all that relevant to *this*
> document)
I think this would be somewhat important so we can get a better view of
the situation... In Portugal (ok, so i know we are small...) some
ISPs/LIRs are closing totally or being bought by bigger ones... this
causes a lot of questions and problems too...
> 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"?
Its better put in Gert's words...
> "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...? ;-)
Is it easy to state a year?
> 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.
Nothing more to say.
Thank you for the time.
Regards,
./Carlos
"Networking is fun!"
"Truth is the biggest of Lies!"
-------------------
cfriacas@localhost, CMF8-RIPE, Wide Area Network WorkGroup http://www.fccn.pt
F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax: +351 218472167
