<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

comments on "Revision of IPv4 policy doc"

  • To: Nurani Nimpuno < >
  • From: Gert Doering < >
  • 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





  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>