<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Thanks Seun and Owen for your comments. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Though i cannot help in rewording, but i am looking forward to reading the new draft and probably will be able to fully support the proposal.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">At this point, i love the spirit behind the proposal as you guys have presented it through your answers to many questions raised here. I think we need this policy.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Until then...</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Arsene<br><br><div>-----------------</div><div>Arsène Tungali,</div><div>@arsenebaguma</div><div>+243 993810967</div><div>GPG: 523644A0</div><div>Goma, Democratic Republic of Congo</div><div><br></div>Sent from my iPhone (excuse typos)</div><div><br>On Apr 14, 2017, at 12:39 PM, Seun Ojedeji <<a href="mailto:seun.ojedeji@gmail.com">seun.ojedeji@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="auto"><div dir="auto">Hello Owen,</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Regards</div><div dir="auto">For the Authors.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Apr 11, 2017 16:25, "Owen DeLong" <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Apr 10, 2017, at 23:58, Douglas Onyango <<a href="mailto:ondouglas@gmail.com">ondouglas@gmail.com</a>> wrote:<br>
><br>
> Hello Owen,<br>
> Thanks for your feedback,<br>
> Comments are inline:-<br>
><br>
>> On 10 April 2017 at 13:21, Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:<br>
>> I believe that the problem statement remains fundamentally flawed and that<br>
>> the resulting policy suffers from those flaws. Clarification in-line<br>
>> below...<br>
>> .<br>
>><br>
>> Specifically, the current Softlanding Policy:<br>
>><br>
>> Allows a maximum allocation size of a /13 in Phase 1. The authors feel this<br>
>> is too large based on average allocation size, and can be abused.<br>
>><br>
>> Please define the perceived "abuse" and explain how it constitutes abuse.<br>
>> Note, I feel that use of loaded terms like "abuse" to describe "a result we<br>
>> don't like" is disingenuous and contrary to open and transparent policy<br>
>> development.<br>
><br>
> To abuse to use improperly, or to misuse. I don’t see why you think<br>
> this is a loaded term.<br>
<br>
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.<br>
<br>
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.<br>
<br>
> On the meaning and use, we believe that Internet resources are<br>
> supposed to be used for the greater good of the AFRINIC community.<br>
<br>
On this we can agree.<br>
<br>
> Based on staff analysis, 93% of the 1,373 v4 requests requests in the<br>
> last 5 years were for blocks smaller than a /16. As authors we believe<br>
> that any policy that favours the 7% of members at the expense of the<br>
> 93% is what is not in the best interest of the greater AFRINIC<br>
> community.<br>
<br>
Here you have gone off the rails. Your description of the situation is nonsensical.<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
> You have seen nefarious elements go as far as hijacking unused v4<br>
> prefixes, so telling ourselves that they won’t come for large chunks<br>
> of v4, if no limits are set, especially for this last pool, then we<br>
> would be burying our heads in the sand.<br>
<br>
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.<br>
<br>
> However, we were careful with any restrictions. Based on our analysis<br>
> more than 93% of organization/requests in the past 5 years could be<br>
> served without a problem if this policy is passed, which represents<br>
> the greater AFRINIC community.<br>
<br>
This implies some inherent assumptions which simply aren't true:<br>
+ There is some magical threshold of size or growth rate above which an<br>
organization's needs are no longer legitimate or are at least less legitimate<br>
or of less benefit to the community than others.<br>
+ That the top 7% of member organizations are somehow not valuable<br>
and contributing members of the community (or at least their growth<br>
is somehow less of a contribution to the larger community than others).<br>
+ That large organizations are inherently less community minded than<br>
smaller ones.<br>
<br>
>>> Allows organizations to request allocations/assignments without limiting the<br>
>>> number of times or maximum size that can be requested. The authors of this<br>
>>> policy feel this can advantage a few, mostly large organizations, at the<br>
>>> expense of the general community, and can also be abused.<br>
>>><br>
>> This perpetuates the myth that large organizations don't serve the general<br>
>> community when in reality, depending on the organization, in some cases,<br>
>> large organizations serve the biggest fractions of the general community.<br>
>> While I can't cite specific examples within the AfriNIC region, I will point<br>
>> out that a /8 being held by a fruit company in Cupertino (ticker symbol<br>
>> AAPL) (large-ish organization that serves a very small fraction of the<br>
>> IP-using community) is probably a very poor use of resources. OTOH, /8s held<br>
>> by various large ISPs actually serve very large fractions of the internet<br>
>> community in the region. Organization size alone is not an effective measure<br>
>> of benefit offered to the community for addresses consumed.<br>
><br>
><br>
> Apologies if we gave this impression. We have tried our level best to<br>
> cater for large organizations. While it is impractical to cater for<br>
> all members at all times, we have catered for 93% of them based on<br>
> requests from the last 5 years We feel that this is representative of<br>
> the greater good.<br>
<br>
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".<br>
<br>
>> The current policy does not "advantage" large organizations in any way.<br>
>> True, you can't fill as many large requests from the remaining free pool as<br>
>> you can smaller requests, but the reality is that customer growth is likely<br>
>> to be roughly the same over the same period of time regardless of whether<br>
>> those customers are connected to a few large providers or a whole lot of<br>
>> smaller ones.<br>
>><br>
>> Preventing larger providers from obtaining addresses for their customers in<br>
>> order to protect the abilities of smaller providers to serve smaller blocks<br>
>> of customers is arguably not so much leveling the playing field as it is<br>
>> creating an advantage for smaller providers at the expense of larger ones.<br>
><br>
> We are not preventing larger providers from obtaining addresses for<br>
> their clients, Like we've stated in our proposal, the current<br>
> statistics shows that a significant percentage of current members got<br>
> space less than a /16. All factors constant, only 7% of the requests<br>
> MIGHT not be met with this policy passing. However, we believe the<br>
> interest of the greater community would have been served.<br>
<br>
Let me see if I can get through by paraphrasing what you said above:<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
As near as I can tell, you are literally arguing that the greater good is served by punishing success.<br>
<br>
>>> Does not make any specific provisions for new entrants. The authors feel<br>
>>> that this might advantage existing organizations at the expense of new<br>
>>> entrants.<br>
>>><br>
>> Please explain why this is a bad thing? Why should we create additional<br>
>> hardships for existing organizations with real needs now on the basis that<br>
>> there might be some other organization that doesn't even exist now which<br>
>> might need addresses at some later date?<br>
><br>
> Perhaps our choice of wording maybe at fault here, but we have<br>
> attempted to make provisions for new entrants without creating<br>
> significant hardship for the existing organizations. From the 5-year<br>
> analysis, we should be able to accommodate 93% of requesters, which we<br>
> feel represents the greater community of existing users. We have been<br>
> careful to make sure any such provision is not at the expense of<br>
> existing users, this is the reason we proposed allocation/assignment<br>
> rounds within phases. So that if a pool still has resources, anyone is<br>
> free to request for more, after a wait period.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Owen<br>
<br>
<br>
</blockquote></div></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>RPD mailing list</span><br><span><a href="mailto:RPD@afrinic.net">RPD@afrinic.net</a></span><br><span><a href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a></span><br></div></blockquote></body></html>