[AfriNIC-rpd] Updated Version of the "IPv4 Soft Landing Policy" now Available Online

[Andrew Alston]

Hi Douglas,

I dispute the consensus on the clause on the 10% allocation.

I refer back to the discussions on the list in the second half of February
this year.

My reading of the thread that was extensive over a few days, we had 10
respondents if I haven't missed any in my reading over it.

Of those 10 from my reading of it, one person who questioned the clause, one
who conceded potential headaches, 4 supports and 4 opposed.  That CLEARLY
indicates lack of consensus in my eyes.

With regards to the minimum allocation size point,

Around the same time when this was discussed on the list, I see a
surprisingly few number of respondents in the thread, but those who DID
respond to that thread voiced objections.  (I can send through a list and
summary as I read it if you wish).  Hence, again, I see no consensus on the
list.

As such, I ask that this policy go back to the public meeting in Dar Es
Salaam for further discussion.

Thanks

Andrew



On 2011/05/03 12:31 PM, "Douglas Onyango" <ondouglas at yahoo.com> wrote:

> 
> Andrew, 
> 
> --- On Tue, 5/3/11, Andrew Alston <aa at tenet.ac.za> wrote:
> 
>> As per previous emails I need to raise concerns with
>> aspects of this
>> document though because these have already been raised time
>> and again on
>> this list, I would like to request discussion of these
>> issues in Tanzania.
>> Once again I submit the following points:
>> 
>>> Exhaustion Phase 2
>>> During this phase a minimum allocation/assignment size
>> will be /27, and
>>> the maximum will be /22 per allocation/assignment.
>>> 
>> To lower the minimum allocation size to a /27 is a self
>> defeating objective.
>> If I recall correctly, and someone from RIPE can let me
>> know if I am wrong
>> here, there is a proposal on the table at RIPE at the
>> moment to take the
>> minimum allocation size back up to a /24, because /27s will
>> get filtered.
>> To allocate /27 P.I space is to allocate blocks that cannot
>> and will not be
>> routed in the DFZ, as they WILL get filtered. There is also
>> a severe danger
>> of people applying for multiple blocks in short succession
>> as their /27s
>> deplete.  It is globally accepted that a /24 is
>> minimum announcable size in
>> the DFZ, and I strongly believe that if an RIR is
>> allocating space, even if
>> the purpose is NOT for DFZ announcement, the possibility
>> for such should
>> remain so as to not make the space useless should the
>> requirement change.
>> 
>> Therefore I object to this and would plead with the
>> community to change this
>> from /27 to /24 in the above paragraph.
> 
> The minimum of /27 is supposed to help LIR/End Users during the transition
> phase with minimal wastage. Albeit, applicants have the option of requesting
> more than a /27 - e.g /24. So i see removing /27 as only encouraging wastage -
> (You must get a plate full of food regardless of whether or not you can finish
> it).
> 
> Also because i feel consensus has been built on this point i am reluctant to
> do anything about it.
> 
> 
>>> AfriNIC resources are for the AfriNIC geographical
>> region. For each
>>> allocation or assignment made during the Exhaustion
>> Phase, no more than
>>> 10% of these resources may be used outside of the
>> AfriNIC region, and
>>> any use outside the AfriNIC region shall be solely in
>> support of
>>> connectivity back to the AfriNIC region.
>> 
>> I object to the above paragraph, STRONGLY and VEHEMENTLY
>> for all the reasons
>> stated in multiple previous emails to this list.  The
>> clause is
>> unenforceable, disadvantages African companies looking to
>> globally expand,
>> and will create serious enforcement and monitoring
>> issues.  For further
>> details on my objection, please see list archives on this
>> topic.  I am also
>> prepared to present at the AfriNIC policy meeting on this
>> topic with a
>> proper presentation should anyone wish it.
> 
> Yes it is true you raised arguments in email threads, and counter arguments
> were raised too. I am again inclined to believe that the bulk of the member
> are Pro this Paragraph and because all Policies are developed through
> Consensus, i will stay this too.....
> 
>>> 3.9 IPv4 Address Space Reserve
>>> 
>>> A /12 IPv4 address block will be in reserve out of the
>> Final /8. This
>>> /12  IPv4 address block shall be preserved by
>> AfriNIC for some future
>>> uses,  as yet unforeseen. The Internet is
>> innovative and we cannot
>>> predict with  certainty what might happen.
>> Therefore, it is prudent to
>>> keep this block in reserve, just in case some future
>> requirement creates
>>> a demand for IPv4 addresses.
>>> 
>>> 3.9.2
>>> When AfriNIC, can no longer meet any more requests for
>> address space
>>> (from the Final /8 or from any other available address
>> space), the Board
>>> may at its discretion and considering the demand and
>> other factors at
>>> the time replenish the exhaustion pool with whatever
>> address space (or
>>> part thereof) that may be available to AfriNIC at the
>> time, in a manner
>>> that is in the best interest of the community.
>>> 
>> This clause needs clarification, because "may be available
>> to AfriNIC" is
>> rather ambiguous, and I would like to see this
>> reworded.   I bring this up
>> SPECIFICALLY because of the debate around legacy IP address
>> space.
> 
> You only point out that the clause has a problem, you didn't point out the
> exactly problem.....perhaps some details would help.
> 
> This Paragraph was written in the spirit of trying to use this Policy to
> allocate/assign any address space that AfriNIC will have going forward without
> the need to write a fresh policy
> 
> Regards,
> Douglas Onyango