[rpd] Report on the Policy Proposal “AFPUB-2016-V4-001-DRAFT07" (IPv4 Soft Landing BIS).

[Owen DeLong]

> On Dec 28, 2017, at 00:36, Noah <noah at neo.co.tz> wrote:
> 
> On 27 Dec 2017 19:13, "Andrew Alston" <Andrew.Alston at liquidtelecom.com> wrote:
> 
> a.) The fact that there were multiple requests – including from the chair of the board in Mauritius – to withdraw this policy – something the authors have not addressed
> 
> But the authors reserved the right to uphelp their policy proposal and based on new recommendations from various members of the PDPWG, they updated their policy proposal which evolved to version.7.
> 
> 
> b.) The fact that entities who had already built infrastructure could not access sufficient space to utilize that infrastructure – vs those who had not yet built infrastructure who wanted the space locked up for future use
> 
> I read "sufficient"
> 
> Andrew, In times of scarcity, version.7 states below. And this is true for each calender year.
> 
> 5.4.6 Allowable Limits
>  
> 5.4.6.1 Within any 24-month period during Exhaustion Phase 1, an organization may receive one or more allocations/assignments totalling the equivalent of a /18.
> 
> Pan African entities would still access more resources from their various local operations to meet the demands in each country of operation. But i stand to be corrected.

That depends a great deal on how AfriNIC chooses to interpret “organization” and how the pan-African entity is organized. 

If it’s a holding company with separate operating entities in each country and each of those entities has a separate org-I’d and separate account with AfriNIC, then perhaps it would be as you say. 

OTOH, if the company is a single entity with a single org-Id and a single account with AfriNIC, this would severely limit their operations. 

> 
> 
> c.) The fact that this policy is damaging to the end user and we act to increase penetration on the continent today rather than just protecting the interests of the ISPs
> 
> How damaging is a max of /18 during period of scarcity where there is only less than a /8 remaining in the inventory.

Very

You are increasing short term scarcity in order to prolong the period of scarcity to delay the onset of exhaustion. 

In reality, for major operators connecting millions of customers, you are effectively accelerating runout. 

> 
> 
> d.) The fact that this policy may well put afrinic in violation of section 3.4.1 of the bylaws
> 
> How????? 
> 
> Anyways, that section of the bylaws says below
> 
> 3.4 
> (i) to provide the service of allocating and registering Internet resources for the purposes of enabling communications via open system network protocols and to assist in the development and growth of the Internet in the African region;
> 

I’ll let Andrew defend this one. I could see that going either way. It’s definitely a gray area. 

Owen

> 
> And SL-BIS version 7 has cretarias of how the said allocations would be achieved. Please see below section of SL-BIS ver.7
> 
> 
> 5.4.3.1 Exhaustion Phase 1
>  
> 5.4.3.1.1 During this phase, allocation/assignment of IPv4 address space will continue as in Pre-Exhaustion with the minimum set at /24, but the maximum will change from /10 to /18, subject to the provisions in 5.4.6
>  
> 5.4.3.1.2 Allocations and assignments will be made from the final /8 or from any other IPv4 address space available to AFRINIC, until no more than a /11 of non-reserved space is available in the Final /8. At this point the exhaustion phase 2 will begin.
>  
> 5.4.3.1.3 For the avoidance of doubt all applications in the process at this point will be evaluated as per the new policy. 
>  
> 5.4.3.2 Exhaustion Phase 2
> Exhaustion Phase 2 will start when no more than a /11 of non-reserved space is available from the final /8. During this phase, the maximum allocation/assignment size will be /22, and the minimum shall remain at /24, subject to the provisions in 5.4.6
>  
> 
> 
> Cheers,
> 
> Noah
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20171228/14313095/attachment-0001.html>