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

Tue Apr 11 14:10:39 UTC 2017

Hi Douglas and Seun,

I appreciate the time and effort you made in putting this proposal
together.
I strongly believe that this proposal is the right policy needed in our
(AFINIC) community at this point in time as AFRINIC Enters IPv4 Exhaustion
Phase 1.
>From the detail of this proposal, it will Reducing the current maximum
prefix in phase 1 and phase 2 and control allocation to organisations who
have been allocated up to the maximum prefixes of /16 for Exhaustion Phase
1 and /20 for Exhaustion Phase 2. Hence giving more room to organization(s)
that want to acquire IPv4 for the first time.
By this, we as a community will achieve one goal of reserving this
resources for organizations that are not yet aware of this resources and
also forcing some organizations that always get this resources from AFRINIC
for the purpose of reselling it to other organization or customers to
direct their customers to AFRINIC.

But on this, 5.4.4.2 Notwithstanding 5.4.4.1, an organization that has
received the maximum allowable prefix in each phase may request for another
round of allocation/assignment in the same phase (as per 5.4.4.1), after a
36 calendar months waiting period.
I think we should consider organization that have genuine reason for more
IP Address, if there case is justifiable for the sake of development of
IP-based technology in Africa.

On these notes, I strongly support this proposal

On Tue, Apr 11, 2017 at 12:44 PM, Douglas Onyango <ondouglas at gmail.com>
wrote:

> 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
>>>
>>
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>

-- 
 ---------------------------------------------------------------

*John C. Ngwoke (JP)*Head, Network section
ICT

*University of Nigeria*Nsukka 410001
*web: http://www.unn.edu.ng <http://www.unn.edu.ng/>*
*Mobile: +2348035723901, +23407017059403*
*Skype:  john.ngwoke*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20170411/1c3854ad/attachment.html>