[rpd] The need to review the existing soft landing policy (was Re: Two more petitioners)

[Owen DeLong]

> On Dec 28, 2017, at 01:56, Noah <noah at neo.co.tz> wrote:
> 
> 
> On 19 Dec 2017 23:44, "Owen DeLong" <owen at delong.com> wrote:
> Now, AfriNIC, the only RIR to still have anything left after all of the other RIRs are either out or well into their final austerity policies is discussing further distorting this timeline in the AfriNIC region.
> 
> I read "left after all of the other RIRs"
> 
> AFRINIC is not the other RIR's, and we are not discussing a global policy. I believe its within her right for the AFRINIC PDPWG members from all walks of life to discuss how best they want their number resources managed regardless of what the RIPE, ARIN, APNIC etc do with their resources.

This ignores the context of my comment. I was responding to someone who claimed that SL-BIS was consistent with the spirit and intent of the global last 5 /8 policy and I believe I adequately showed that it was not. 

Of course, we, the AfriNIC community have the right to develop any policy we like so long as there is consensus. The problem is that in this case, there are so many clear objections that calling it consensus flies in the face of any rational definition of the words rough consensus. 

> 
> 
> Such a distortion remains a disservice to the global internet community as well as a disservice to the African internet community as well.
> 
> A disservice to the global internet community how????  

1. Reducing the rate at which internet services can be deployed within Africa
2. Extending the already protracted timeline for deployment of IPv6 within the AfriNIC region
3. Creating additional uncertainty around the IPv4 free pool. 
4. Creating an illusion that a new business with an IPv4 only strategy may be viable. 
5. Increasing the deployment of harmful technologies like carrier grade NAT. 
6. Depriving providers who have already made significant investments in infrastructure of the addresses needed to deploy that investment and produce revenue. 

I’m sure there are more, but these come immediately to mind. 

> 
> The fact is that the SL-BIS policy proposal in sections sections 5.4.3.1 and 5.4.3.2  stipulates how section 3.4.(i) of the AFRINIC's bylaws could still be achieved for the best interest of the AFRINIC service region and her mandate as a central registry for AFRICA. 

We can agree to disagree about this. 

> 
> In fact I would say that, since 2004, the AFRINIC region has been of great service to the African and global Internet community and will continue to be. 

I would agree. That doesn’t change the fact that enacting this policy despite the significant opposition would be harmful to the continuance of that service. 

> 
> 
> 
> Your idea of “fair distribution” involves depriving service providers trying to connect real users today in favor of making sure that possible future service providers which don’t yet exist and may well never exist can get some amount of space to connect a very limited number of real users each at some point in some imagined future.
> 
> 
> Nothing in the SL-BIS ver.7 policy proposal talks about favoring some future service providers which dont exist.  I would be happy for you to show me that specific section.

The provisions which call for a set-aside for new entrants do exactly that. 

> 
> The fact is that the SL-BIS proposal as it stands in version 7 does not stop live and operating ISP's/Resource members of AFRINIC from obtaining additional IPv4 resources.  The guidelines for the distribution of the scarce /8 are pretty straight and I will refer you back to SL-BIS version 7 sections sections 5.4.3.1 and 5.4.3.2  and finally section 5.4.7 IPv6 deployment reserve. .

It severely limits the amount they can get and thus favors providers connecting very small numbers of end users and virtually forces carrier grade NAT onto anyone attempting to connect larger numbers of end users to the internet. 

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20171228/1fec760f/attachment.html>