Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[AFRINIC-rpd] IPv4 Address Allocation and Assignment proposal

sm+afrinic at sm+afrinic at
Tue Jan 22 21:21:10 UTC 2013

Hi Owen,

Thanks for the feedback.  I'll comment inline.

At 12:01 22-01-2013, Owen DeLong wrote:
>It seems to me that paragraphs 2.3 and 2.5 are virtually identical 
>and should be consolidated into a single
>combined definition of the interchangeable terms LIR and ISP.

I left it in as there are occurrences of "ISP" in other 
sections.  I'll wait for other people to comment on whether there are 
ISPs in Africa which are not LIRs to see whether to combine 2.3 and 2.5.

>The definition in 2.6 is utterly vague and not necessarily accurate. 
>I have, for example, been an end-user of
>many community networks with which I had no legal or commercial relationship.

That's the definition which is currently used.  I'll wait for 
feedback from people who have been had problems justifying their 
requests to get a better view of the problem.

>The wording in 2.8 which claims that a delegation to an ISP is an 
>assignment and not an allocation seems
>incorrect and should be moved to 2.7 since ISP and LIR are 
>essentially the same in this regard.

There is a mention of "downstream ISPs" in Section 7.4.  See for 
information about eligibility for resource requests.

>2.10 -- Why does PI space have to be assigned through an LIR? Why 
>not support end-users being able
>to get PI space directly from the RIR? I know RIPE-NCC does not do 
>this, but ARIN, LACNIC, and APNIC
>all support direct PI assignments.

PI space is covered by a different policy.  Section 2.10 can be 
removed if it is not a problem for anyone in the service region.

>7.1 --
>While I think /22 is valid for minimum allocation, if you take my 
>suggestion to allow direct assignments,
>the minimum assignment size should probably be /24.

That's already the case as there is an existing policy for end users.

>Enumerating each of the RIRs seems like a potential time-bomb. What 
>happens if another RIR is
>added and nobody remembers to update this document? Why not just 
>collectively refer to them as
>the various RIR Whois databases?

Yes. :-)  I'll try to find some appropriate wording.

>9 -- The sub-allocation window should probably also apply to assignments.

Yes.  I'll change that to "may sub-allocate or assign".

>9.1(b) is indecipherable to me. I have no idea what you are trying to say.
>As near as I can tell, under 9.1(a)+9.1(b) a new LIR can never 
>allocate anything.

That's from the existing policy.  9.1 (a) applies to a new LIR.  9.1 
(b) applies to LIRs who have a non-zero SAW.  9.1 (b) could be:

   (b) A LIR cannot make any sub-allocation to the end user above their
       SAW in a 12 months period (one calendar year).  In case the LIR's
       SAW is exhausted for a particular end user, approval must be sought
       from AfriNIC for any other sub-allocation to the same end user.

Section 9 could be:

   A sub-allocation window (SAW) refers to the maximum number of IPv4 addresses
   that the LIR may sub-allocate or assign to end users within a calendar year
   without seeking approval from AfriNIC.

S. Moonesamy 

More information about the RPD mailing list