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

Fri Apr 14 10:39:14 UTC 2017

Hello Owen,

Thanks for your comments which are well noted. We will reword the problem
statement to ensure such interpretations as you've indicated are minimised
(if not entirely eradicated) and rather emphasis the intent of the
proposal. Specifically among other things, we intend the proposal to ensure
"fair distribution of the last pool across members as much as feasible"
thereby reducing a situation where the pool is exhausted by a few
organisations/members. We welcome suggestion on wordings that helps achieve
the intent stated.

With regard to the max prefix, we arrived at /16 by looking at the average
allocation and we also found that the prefix satisfies the needs of most
members in the past and that's why we went for it (it's also inline with
the feedback we got from the community). We recognise that this may not
meet the entire needs of a few other members however we believe further
increase in the prefix would defeat the intent of the proposal (as earlier
indicated above). In other to minimise the impact on such members we
introduced option for members to return to request resources multiple
times as feasible.

Regards
For the Authors.

On Apr 11, 2017 16:25, "Owen DeLong" <owen at delong.com> wrote:

>
>
> > On Apr 10, 2017, at 23:58, Douglas Onyango <ondouglas at gmail.com> wrote:
> >
> > Hello Owen,
> > Thanks for your feedback,
> > Comments are inline:-
> >
> >> On 10 April 2017 at 13:21, Owen DeLong <owen at delong.com> 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.
>
> Because in this context, "abuse" carries a very negative connotation and
> an accusation towards those that use the policy in a manner you happen to
> dislike.
>
> Please provide a solid clear definition of what distinguishes legitimate
> use of the policy as written vs. abuse which remains within the limits of
> the policy as it exists today.
>
> > On the meaning and use, we believe that Internet resources are
> > supposed to be used for the greater good of the AFRINIC community.
>
> On this we can agree.
>
> > 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.
>
> Here you have gone off the rails. Your description of the situation is
> nonsensical.
>
> Let's analyze this by the numbers. If a /16 or smaller block meets the
> needs of 93% of member organizations, that's an indication that those
> organizations are growing by less than ~65,000 customers per time period.
>
> How does that mean that the 7% of organizations that are growing by more
> than ~65,000 customers per time period are somehow less entitled to those
> same resources? How do you defend the inherent assumption in this argument
> that claims those organizations don't serve a larger fraction of the
> greater AfriNIC community than the smaller organizations?
>
> There are organizations (large and small) that may not operate in the best
> interests of the community. However, basing policy on an inherent
> assumption that large organizations are less likely to operate in the
> interests of the community is not just bad judgment, it's mathematically
> incorrect and grossly unfair to the larger AfriNIC community in the form of
> the users served by member organizations both large and small.
>
> > 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.
>
> The limits should be set by a legitimate needs test and/or by shortening
> of the time horizon on requests to ensure a more fair distribution. It is
> actually smaller organizations that have done the hijacking. I know of no
> case where an organization that would likely qualify for more than a /16
> under current policy has been caught hijacking unused IPv4 addresses. If
> you can point to an example, please do as I think it would be a very
> interesting data point. If you cannot, then the above paragraph is a non
> sequitur and presents a specious argument appealing to an emotional
> reaction independent of the actual facts at hand.
>
> > 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.
>
> This implies some inherent assumptions which simply aren't true:
> +       There is some magical threshold of size or growth rate above which
> an
>         organization's needs are no longer legitimate or are at least less
> legitimate
>         or of less benefit to the community than others.
> +       That the top 7% of member organizations are somehow not valuable
>         and contributing members of the community (or at least their growth
>         is somehow less of a contribution to the larger community than
> others).
> +       That large organizations are inherently less  community minded than
>         smaller ones.
>
> >>> 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.
>
> While you apologize for giving that impression, you stick to the argument
> that the arbitrary dismissal of the fastest growing 7% of member
> organizations as somehow being less beneficial to the greater good than the
> smaller 93%. Can you please offer some evidence or other legitimate
> supporting argument to back up this conclusion? If not, then I seriously
> suggest that you reconsider your definition of "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.
>
> Let me see if I can get through by paraphrasing what you said above:
>
> All factors constant, our proposal would only disadvantage the fastest
> growing 7% of member organizations and we think that is an acceptable level
> of unfairness in support of the greater community.
>
> Can you explain to me how an ISP that is growing by 100,000 customers per
> year provides less service to the community than an ISP that is growing by
> 500 customers per year? Can you explain to me why it is somehow a higher
> purpose to provide addresses to 100 ISPs growing by 10,000 customers per
> year than it would be to serve one ISP that grows by 1,000,000 customers in
> that same year?
>
> In either case, you are looking at a growth of 1,000,000 customers on the
> internet. Arguably, an ISP which can attract 1,000,000 customers must be
> doing something better than the ISPs that are only able to attract 10,000
> customers in that same time period.
>
> As near as I can tell, you are literally arguing that the greater good is
> served by punishing success.
>
> >>> 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.
>
> You assume that all requests have the same value to the community per
> request. This is an erroneous assumption. A larger request is (generally)
> made by a faster growing provider that is serving a greater fraction of the
> community with the numbers they are requesting. A /12 generally serves
> ~1,000,000 customers, regardless of whether it is justified by a single
> rapidly-growing provider or by 16 or more smaller providers that fit into
> your 93% magic threshold.
>
> Yes, you've been very careful to make sure that you only punish the
> fastest growing 7% of providers. This makes sense if you're looking at a
> popular vote because you should be able to easily ignore the interests of
> that 7% voting block even though they represent a much larger percentage of
> the end-users that would be impacted by such a move.
>
> Fortunately, policy is about consensus and not majority rule, so hopefully
> the mathematical facts of the situation can not be drowned out by the
> rhetoric.
>
> Owen
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20170414/280ecc4a/attachment-0001.html>