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

[Owen DeLong]

I believe that the problem statement remains fundamentally flawed and that the resulting policy suffers from those flaws. Clarification in-line below...
> <Begin Draft>
> 1. Summary of the problem being addressed by this proposal
> 
> The current Soft-Landing Policy describes how AFRINIC should manage allocations/assignments from the last /8.
> 
> While the stated policy objective is to ensure that allocations/assignments are managed in a manner that is acceptable to the AFRINIC community, there is a general feeling from the AFRINIC community that certain provisions in the policy are not consistent with this objective.
> 
> 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.
> 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.

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.
> 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?

It would be akin to having a tank of potable water and refusing to allow thirsty people to fill their canteens because there might be a drought next year.

If your IPv4 need doesn't already exist, then it's probably a really bad time to be considering starting a business that depends on IPv4. We need to move beyond this idea that we can somehow continue to artificially extend the useful life of IPv4 and stop helping people buy into this illusion that IPv6 is an optional change.

Anyone who hasn't already figured these things out from the 20+ years of warning and 4+ years of post-IANA-depletion experience that we now have really doesn't deserve special policy consideration moving forward.

> 2. Summary of how this proposal addresses the problem
> 
> This proposals tries to address these problems by: 
> 
> Reducing the maximum prefix in phase 1. We arrived at this figure by looking at the average allocation prefix. We found the average to be between /17 and /16.
Reducing the maximum prefix to match the average allocation size simply guarantees that you are knee-capping the top 50% of providers in the region to subsidize the bottom 50%.
> Disallowing allocation to organisations who have been allocated up to the maximum prefixes during each phase for certain duration.
This simply insures that the knee-capping in the previous provision has maximal effect on a potentially expanded fraction of the community.
> Adjusted the maximum prefix for phase 2, to bring it closer to average allocation size.
It's not entirely clear whether that is an expansion or a reduction in the maximum prefix size, nor am I sure it matters given the above flaws.

Owen

> 3. Proposal
> 
> Modify Section 5.4.3.1 of the CPM to the following:
> 
> Exhaustion Phase 1:
> 
> During this phase, allocation/assignment of address space will continue as in the Current phase (/24 for a EU and /22 for a LIR) but the maximum will change from /10 to /16.
> 
> Modify Section 5.4.3.2 of the CPM to the following :
> 
> Exhaustion Phase 2
> 
> During this phase a minimum allocation/assignment size will be /24, and the maximum will be /20 per allocation/assignment.
> 
> Modify section 5.4.4 of the CPM to the following:
> 
> For any LIR or End User requesting IPv4 address space during the Exhaustion phases:
> 
>  5.4.4.1 An organization may request additional IPv4 address space in both Phase 1 and Phase 2. However, such an organisation's total allocations/assignments must not exceed the maximum allowable prefix of /16 for Exhaustion Phase 1 and /20 for Exhaustion Phase 2.
> 
>  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.
> 
>  4. Revision History
> 
> Version 2.0
> 
> Modification of maximum prefix allowed during phase 1 based on staff analysis and community feedback
> Modification of section 2 of the proposal, specifically to provide justification for change in prefix which is based on community feedback and staff analysis
> Re-wording and renumbering of section 5.4.4,  specifically to provide more clarity based on community feedback and ensure that exhaustion is steady enough. It also ensures that new entrants are granted sufficient opportunity to acquire space by disallowing early return of existing members who have reached their maximum prefix in the respective phases.
> Addition of revision history to section 4
> <End Draft>
> Draft url: http://afrinic.net/en/community/policy-development/policy-proposals/2055-soft-landing-sd
> 
> 
> -- 
> ------------------------------------------------------------------------
> Seun Ojedeji,
> Federal University Oye-Ekiti
> web:      http://www.fuoye.edu.ng
> Mobile: +2348035233535
> alt email: seun.ojedeji at fuoye.edu.ng
> 
> Bringing another down does not take you up - think about your action!
> 
> _______________________________________________
> 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/20170410/fbd40a35/attachment-0001.html>