[rpd] Summary of proposals: IPv4 Runout Management

[Andrew Alston]

Noah,

The current policy is needs based – completely.

I presume you haven’t done an application recently since you’re sitting on that /12 at your current employer and haven’t seen just how difficult it is to get space and justify it, so its understood that you don’t quite see just how needs based it currently is and how strictly its enforced.

And yeah – it’s easy to support it when you’re sitting on a /12 worth of space and can allocate to customers while your competition has to pay out masses of money to do exactly what you can do for no cost.  But no one begrudges you that, you got the space legitimately with a legitimate application.  I just want everyone else to have the same opportunities.

Andrew


From: Noah [mailto:noah at neo.co.tz]
Sent: 08 November 2016 23:34
To: Andrew Alston <Andrew.Alston at liquidtelecom.com>
Cc: rpd List <rpd at afrinic.net>; Frank Habicht <geier at geier.ne.tz>
Subject: RE: [rpd] Summary of proposals: IPv4 Runout Management


On 8 Nov 2016 23:20, "Andrew Alston" <Andrew.Alston at liquidtelecom.com<mailto:Andrew.Alston at liquidtelecom.com>> wrote:
>
>
> So once again – I oppose this policy – for every reason I have stated time and again – and now based on these calculations which show that this policy just screws the newcomer, screws the consumer, and benefits the large players who already have space and established infrastructure.
>
>

This policy is actually great for new comers and consumers because it need based rather than finish that soft landing space fast by allocating it to folks who need it now now.

ISP with huge space tend to sub allocate to their customers who can justify the need without a problem as this has been the practice all along. No one wants to loose a customer.

Some ISP even recommend new consumers to get own allocations from Afrinic and they surely will need to find some available IPv4 space as the IPv6 internet continues to grow sponteneously.

>
> Andrew
>

Noah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20161108/e86f47df/attachment.html>