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

Tue Apr 11 11:44:00 UTC 2017

Dear Barrack,
On 11 Apr 2017 14:42, "Barrack Otieno" <otieno.barrack at gmail.com> wrote:

Dear all,

I support this proposal.

Thanks. Noted.

Best Regards
On Apr 11, 2017 1:59 PM, "Barrack Otieno" <otieno.barrack at gmail.com> wrote:

> 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/d1d0212b/attachment.html>