[rpd] Statistics on IPV4 allocation in Africa as of 2016

[Owen DeLong]

> On Jun 16, 2016, at 06:15, Andrew Alston <Andrew.Alston at liquidtelecom.com> wrote:
> 
> Fabian,
>  
> In one sense you have it right, in another sense you verbalize half the problem.
>  
> You state:
>  
> i think we need to push R&D as fast as possible to resolve these issues..
>  
> That is correct – we do.
>  
> Yet, at the same time you say:
>  
> i hope ISOC (IETF) and IANA (ICANN) are on their toes ..............
> 
> and
>  
> i also hope that the Computer Science Laboratories who invented packet networking and new ones are still doing R&D on IPv6..........
> 
> Here is the issue - *WE* are the IETF, the IETF is driven from the bottom up.  I was in Texas, in San Antonio, in Feb 2015, and they were talking about what people who are surveyed about the IETF say.  One of the questions that was asked was, why is there the lack of involvement from operators.  The answer?  Most of the operators say “We leave that to our vendors” (In excess of 70% of those surveyed if I recall)
>  

Another point that may not be a popular point of view here, nut must be raised... The remaining work to be done is largely not in scope for IETF or IANA/ICANN. 

IETF's role is protocol design and specifications, not implementation. The specifications needs by and large exist at this point. Implementation is up to vendors and/or the open source community. 

IANA's role is the record keeping of the central number registries (protocol related numbers, addresses, ASNs) as delegated to them from IETF. 

ICANN's role in this matter is that they are the current service provider of IANA functions as delegated by the US NTIA. Hopefully this contract will soon be administered by the community in the form of the NRO for addresses and ASNs and the IETF for protocol related numbers and whatever new mess is replacing the old mess for domain names. 


> Now, think about it, is it really in the vendors interests to have all this working smoothly and at low costs?  No, it is in the vendors interests to introduce features piece by piece, one piece of equipment at a time, to force upgrade after upgrade after upgrade.  It is in the vendors interests to propagate the lie that is CGN, in the same way the vendors sold the biggest lie ever told on the internet, that “NAT Was a security mechanism”, so they could sell more boxes.

I disagree. What you describe is what is in the interests of a monopoly vendor or a cartel of vendors. 

In a market with informed consumers, it is in the best interests of the vendors to develop products that consumers will buy. The trick here is that we seem to have plenty of consumers willing to accept the conduct you describe. If we collectively demand better products, the vendors will produce them. If we continue to purchase substandard products from vendors, they will happily continue to sell them to us. 

We are in the drivers seat on what gets developed. So far, we've been largely asleep at the wheel. 

> Prolonging v4 will not help that pressure build either, it is yet another excuse that the vendors can hide behind saying, we don’t need to do that, you have v4 space.  Again, I am NOT saying we should burn all v4 overnight.  I am NOT saying we should waste the resources.  I am saying that they should be allowed to follow a natural depletion course and that those who need them *now* should be able to access them, with the only limitation being that the space is being used to connect the *consumers*.  I am saying that we should stop thinking about just ourselves as operators, and start looking at what is good for the *consumers*, who need access *today*, free of the limitations of NAT, free of the constaints placed by artificially limiting demand for v4.  And once it’s all gone, the world will adjust and move on, but artificially stringing it out, doesn’t help anyone.

Very well said. 

This is exactly what I've been trying to express.

Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20160616/883ce027/attachment-0001.html>