Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] Soft Landing-SD (AFPUB-2017-V4-001-DRAFT-02)

Mark Elkins mje at
Tue Apr 11 08:09:25 UTC 2017

On 11/04/2017 08:58, Douglas Onyango wrote:
> Hello Owen,
> Thanks for your feedback,
> Comments are inline:-
> On 10 April 2017 at 13:21, Owen DeLong <owen at> wrote:
>> I believe that the problem statement remains fundamentally flawed and that
>> the resulting policy suffers from those flaws. Clarification in-line
>> below...
>> .
>> Specifically, the current Softlanding Policy:
>> Allows a maximum allocation size of a /13 in Phase 1. The authors feel this
>> is too large based on average allocation size, and can be abused.
>> Please define the perceived "abuse" and explain how it constitutes abuse.
>> Note, I feel that use of loaded terms like "abuse" to describe "a result we
>> don't like" is disingenuous and contrary to open and transparent policy
>> development.
> To abuse to use improperly, or to misuse. I don’t see why you think
> this is a loaded term.
> On the meaning and use, we believe that Internet resources are
> supposed to be used for the greater good of the AFRINIC community.
> Based on staff analysis, 93% of the 1,373 v4 requests requests in the
> last 5 years were for blocks smaller than a /16. As authors we believe
> that any policy that favours the 7% of members at the expense of the
> 93% is what is not  in the best interest of the greater AFRINIC
> community.
> You have seen nefarious elements go as far as hijacking unused v4
> prefixes, so telling ourselves that they won’t come for large chunks
> of v4, if no limits are set, especially for this last pool, then we
> would be burying our heads in the sand.
> However, we were careful with any restrictions. Based on our analysis
> more than 93% of organization/requests in the past 5 years could be
> served without a problem if this policy is passed, which represents
> the greater AFRINIC community.

So you are stating we are more concerned with Members rather than the
people that they serve - the End Users. A large member will serve
proportionally a large number of end users - and probably do it more
efficiently than a small member.

The only perceived abuse here is potentially abuse from their size - if
they get more space explicitly to deprive smaller members for getting
space in order to make competition difficult for smaller members. In
truth, this should be the communities only worry. Reducing the time
period (allocation and assignment period) that the IP's should be used
by should help. Perhaps reduce this further from 8 to 6 months? Then
after 6 months, people can go witch hunt if concerned?

I see we now allow people to come back for a second /16 of IPv4
addresses after three years. Perhaps make this two or even one year -
especially if the allocation and assignment period is set to six months.

Otherwise, as large members already have a large block of numbers, when
they ask, they can ask for a large block. Small members don't like this
- even although the large member goes on to properly use them to bring
large groups of users on to the Internet. Outsiders may call this jealousy.

The only thing I can think of is if we throttle the large members from
not getting IPv4, they may implement and drive IPv6 to the advantage of
the rest of us. As they have more money and I am small - maybe that's

I know we shouldn't tie IPv6 to the last /8 but if we did then use of
IPv6 should be, the ISP has a IPv6 block, has put it in the routing
table, answers DNS via IPv6, has mail delivery via IPv6  and web servers
using IPv6 on their own network  - as a minimum requirement.

> Allows organizations to request allocations/assignments without limiting the
> number of times or maximum size that can be requested. The authors of this
> policy feel this can advantage a few, mostly large organizations, at the
> expense of the general community, and can also be abused.
> This perpetuates the myth that large organizations don't serve the general
> community when in reality, depending on the organization, in some cases,
> large organizations serve the biggest fractions of the general community.
> While I can't cite specific examples within the AfriNIC region, I will point
> out that a /8 being held by a fruit company  in Cupertino (ticker symbol
> AAPL)  (large-ish organization that serves a very small fraction of the
> IP-using community) is probably a very poor use of resources. OTOH, /8s held
> by various large ISPs actually serve very large fractions of the internet
> community in the region. Organization size alone is not an effective measure
> of benefit offered to the community for addresses consumed.
> Apologies if we gave this impression. We have tried our level best to
> cater for large organizations. While it is impractical to cater for
> all members at all times, we have catered for 93% of them based on
> requests from the last 5 years We feel that this is representative of
> the greater good.
>> The current policy does not "advantage" large organizations in any  way.
>> True, you can't fill as many large requests from the remaining free pool as
>> you can smaller requests, but the reality is that customer growth is likely
>> to be roughly the same over the same period of time regardless of whether
>> those customers are connected to a few large providers or a whole lot of
>> smaller ones.
>> Preventing larger providers from obtaining addresses for their customers in
>> order to protect the abilities of smaller providers to serve smaller blocks
>> of customers is arguably not so much leveling the playing field as it is
>> creating an advantage for smaller providers at the expense of larger ones.
> We are not preventing larger providers from obtaining addresses for
> their clients, Like we've stated in our proposal,  the current
> statistics shows that a significant percentage of current members got
> space less than a /16.  All factors constant, only 7% of the requests
> MIGHT not be met with this policy passing. However, we believe the
> interest of the greater community would have been served.
>> Does not make any specific provisions for new entrants. The authors feel
>> that this might advantage existing organizations at the expense of new
>> entrants.
>> Please explain why this is a bad thing? Why should we create additional
>> hardships for existing organizations with real needs now on the basis that
>> there might be some other organization that doesn't even exist now which
>> might need addresses at some later date?
> Perhaps our choice of wording maybe at fault here, but we have
> attempted to make provisions for new entrants without creating
> significant hardship for the existing organizations. From the  5-year
> analysis, we should be able to accommodate 93% of requesters, which we
> feel represents the greater community of existing users. We have been
> careful to make sure any such provision is not at the expense of
> existing users, this is the reason we proposed allocation/assignment
> rounds within phases. So that if a pool still has resources, anyone is
> free to request for more, after a wait period.
> From the Policy Authors.
> Regards,
> _______________________________________________
> RPD mailing list
> RPD at

Mark James ELKINS  -  Posix Systems - (South) Africa
mje at       Tel: +27.128070590  Cell: +27.826010496
For fast, reliable, low cost Internet in ZA:

More information about the RPD mailing list