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

Tue Apr 11 10:59:12 UTC 2017

Many thanks Douglas,

Regards
On Apr 11, 2017 11:44 AM, "Douglas Onyango" <ondouglas at gmail.com> wrote:

> Hi Barrack,
> Thanks for the contribution.
> On 11 Apr 2017 11:21, "Barrack Otieno" <otieno.barrack at gmail.com> wrote:
> >
> > Hi Douglas and Seun,
> >
> > Many thanks for the proposal. With regard to some of the issues raised
> by Owen, i am seeing massive FTTH roll outs in Kenya and i am of the
> opinion that demand for address space will increase exponentially thus
> commercial operators will ask for bigger allocations. Most citizens are
> still buying used computers for use at home due to the cheap cost USD 100
> for PC and USD 200 for a decent laptop. Can you consider this scenario in
> your proposal for allocation?
> >
>
> This scenario is appropriately catered for in the policy.
>
> Based our analysis of the 1,373 requests made in the last 5 years,
> /24, /22 & /21 were the most requested blocks. With the new policy
> proposal, organizations that requested these blocks now have the
> opportunity to request up to a /16 is Phase 1 alone. This effectively
> gives these member organizations an expansion room of 32-times what
> they have currently.
>
> More to this, should they have need for more resources within a phase,
> than the maximum possible  (/16 in Phase 1 & /20 in Phase 2) they are
> welcome to request for it as long as the poll still has some
> resources.
>
> Regards,
>
>
>
> > Regards
> >
> > On Apr 11, 2017 10:01 AM, "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.
> >>
> >> 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.
> >>
> >>
> >> >
> >> > 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 afrinic.net
> >> https://lists.afrinic.net/mailman/listinfo/rpd
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20170411/9869359d/attachment.html>