<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 19, 2017, at 10:29 , Omo Oaiya <<a href="mailto:Omo.Oaiya@wacren.net" class="">Omo.Oaiya@wacren.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="auto" class=""><div class="">Sander,</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">This discussion is increasingly moot but I thought I'd chip in anyway because I found the RIPE-NCC proposal interesting for obvious reasons and followed it closely.  I recall someone also posted the announcement on this list when it was proposed.</div><div dir="auto" class=""><br class=""></div><div class="">The only similarity for me was that it made almost the same arguments as SL-BIS, a year after it was proposed in AfriNIC.  One might even think it was inspired by discussions here.</div><div class=""><br class=""></div><div class="">2 main differences in my mind:</div><div class=""><br class=""></div><div class="">- the significant regional differences (internet penetration, more even distribution of resources in the RIPE region and the amount of IPv4 left in RIPE-NCC[1] 5 years after projected runout amongst others)</div><div class=""><br class=""></div><div class="">- unlike the corresponding RIPE proposal, SL-BIS has seen many iterations in AfriNIC as pointed out and this is the second time it has reached last call, each time with considerable community input, in modifications and supplied text.  Even now, the objections do not reflect the majority view in my opinion and fails to appreciate the intent and spirit behind the allocation of the last /8.<br class=""></div></div></div></div></blockquote><div><br class=""></div>With all due respect, Omo, I think I fully appreciate the intent and spirit behind the allocation of the last /8.</div><div><br class=""></div><div>Indeed, I don’t see any relationship between SL-BIS and the actual intent and spirit behind the global policy under which the last 5 IANA reserved /8s were distributed to the RIRs.</div><div><br class=""></div><div>The spirit and intent (at least as expressed at multiple meetings I attended where it was discussed and eventually reached consensus) of the last /8 global policy proposal was to make sure that each RIR had a reliable and predictable end-condition that they could plan for as IANA ran out of IPv4. It was intended that each RIR community could develop their own plan and policies for the end of their particular IPv4 free pool. Indeed, despite the grotesque unfairness of distributing IPv4 in this manner, the global community came to consensus that this was the best way to distribute the last 5 /8s from the IANA reserved pool in order to allow each RIR community to have a reliable  nearly equal length runway towards winding down IPv4 allocations.</div><div><br class=""></div><div>At the time, nobody expected the differences in runout at the 5 RIRs to be so widely dispersed across time. Indeed, most of us predicted that all 5 RIRs would probably run out within 1-2 years of each other.</div><div><br class=""></div><div>Much of the unanticipated distortion in this expectation can be traced to differences in run-rate at the various RIRs which simply wasn’t accounted for in most of our minds at the time. However, another significant contributing factor is the dispersion of “soft-landing” policies that came up in the various RIRs.</div><div><br class=""></div><div>Now, AfriNIC, the only RIR to still have anything left after all of the other RIRs are either out or well into their final austerity policies is discussing further distorting this timeline in the AfriNIC region. Such a distortion remains a disservice to the global internet community as well as a disservice to the African internet community as well.</div><div><br class=""></div><div>Your idea of “fair distribution” involves depriving service providers trying to connect real users today in favor of making sure that possible future service providers which don’t yet exist and may well never exist can get some amount of space to connect a very limited number of real users each at some point in some imagined future.</div><div><br class=""></div><div>Don’t get me wrong, I enjoy reading a good revisionist history novel as much as the next person and the one you’ve written here isn’t the worst I’ve ever read, but let’s recognize it for the fiction that it is and if we want to talk about the spirit and intent of the global policy governing the distribution of the last 5 /8s from IANA, let’s at least talk about it with an accurate historical perspective.</div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div dir="auto" class=""><div class="">Your portrayal does not reflect these realities and seems to ignore the fact that you need consensus to get to last call, unlike the RIPE-NCC proposal that didn't make the first meeting.  </div></div></div></div></blockquote><div><br class=""></div>Well… In the case of this policy, the co-chairs also seem to have ignored the fact that you are supposed to have consensus to get to last call as well. The record clearly shows that despite the declaration of the co-chairs, no such consensus actually existed and that still no such consensus exists, no matter how much you would like to pretend that a simple majority (which I’m not convinced is even present here) constitutes consensus.</div><div><br class=""></div><div>I will again quote from RFC 7282… The very header of section 2 sums it up quite well:</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><pre class="newpage" style="font-size: 13.333333015441895px; margin-top: 0px; margin-bottom: 0px; break-before: page;"><span class="h2" style="line-height: 0pt; display: inline; font-size: 1em; font-weight: bold;"><h2 style="line-height: 0pt; display: inline; font-size: 1em;" class=""><a class="selflink" name="section-2" href="https://tools.ietf.org/html/rfc7282#section-2" style="color: black; text-decoration: none;">2</a>.  Lack of disagreement is more important than agreement</h2></span></pre></div></blockquote></blockquote><div><div class=""><br class=""></div>Thus, your dismissal of not just a single or a few disagreements, but the many many disagreements that still plague this policy is simply out of line for a consensus based decision process. Please read RFC 7282 and come to understand the concept of consensus based decision making. I encourage the co-chairs to do so as well.</div><div><br class=""></div><div>Mistakes have been made in the PDP implementation around this policy. In the first round, we attempted to politely point out the error, the right thing happened in the end (determination of no-consensus) and we hoped that everyone learned from the experience. Unfortunately, the fact that this has happened again proves that the lessons were not learned last time and so some of us feel that stronger measures and corrective action are necessary. Thus we have brought an appeal before the RPD and asked that the appeal committee proceed with nullification of the erroneous decision to send this proposal to last call.</div><div><br class=""></div><div>Owen</div><div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">My 0.02</div><div class="">Omo</div><div dir="auto" class=""><br class=""></div><div dir="auto" class=""><div class="gmail_extra" dir="auto">1 - <a href="https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph" target="_blank" class="">https://www.ripe.net/publicati<wbr class="">ons/ipv6-info-centre/about-ipv<wbr class="">6/ipv4-exhaustion/ipv4-availab<wbr class="">le-pool-graph</a></div><div class="gmail_extra" dir="auto"><br class=""></div><div class="gmail_extra" dir="auto"><br class=""><div class="gmail_quote">On 19 Dec 2017 6:07 p.m., "Sander Steffann" <<a href="mailto:sander@steffann.nl" target="_blank" class="">sander@steffann.nl</a>> wrote:<br type="attribution" class=""><blockquote class="gmail-m_-5787511240272686568m_-2717196887959088731m_-8749424240553752134gmail-m_-2736051291208488242quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Alain,<br class="">
<div class="gmail-m_-5787511240272686568m_-2717196887959088731m_-8749424240553752134gmail-m_-2736051291208488242quoted-text"><br class="">
> We have gone a long way with the discussions about the existing softlanding policy and the merits of the various proposals to amend it. The version of SL-BIS  which went to last call is a merger of two of them.<br class="">
<br class="">
</div>Yes, and despite that there doesn't seem to be consensus that it is better than the existing soft landing policy. In a consensus-based policy development process there is a built-in bias against change: change only happens when there is consensus on a policy proposal. If there is no such consensus then the default is to keep the existing policy.<br class="">
<br class="">
There is nothing wrong with this. I have seen many proposals that at first seem to be a great idea, but later in the process problems are identified that cannot be solved. At that point the best thing to do is to withdraw the proposal.<br class="">
<br class="">
I encountered something similar in my own region. We had a policy proposal to slow down our version of the soft landing proposal: <a href="https://www.ripe.net/participate/policies/proposals/2017-03" rel="noreferrer" target="_blank" class="">https://www.ripe.net/participa<wbr class="">te/policies/proposals/2017-03</a>. I personally was very much in favour of this, but discussion on the mailing list showed that the opinions were strongly divided on this. In the end the authors together with the working group chairs decided to withdraw the proposal because finding consensus would very likely be impossible, and keeping the proposal going would most likely be a waste of everybody's time.<br class="">
<br class="">
There is no shame in not finding consensus on a policy proposal. It just shows that the existing policy has more consensus (self-evident, because it did get through the PDP successfully) than the proposed changes. Sometimes it is very frustrating because we feel very strongly about a proposal, but in the end we have to respect what the community as a whole wants.<br class="">
<br class="">
Cheers,<br class="">
Sander<br class="">
<br class="">
<br class="">______________________________<wbr class="">_________________<br class="">
RPD mailing list<br class="">
<a href="mailto:RPD@afrinic.net" target="_blank" class="">RPD@afrinic.net</a><br class="">
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer" target="_blank" class="">https://lists.afrinic.net/mail<wbr class="">man/listinfo/rpd</a><br class="">
<br class=""></blockquote></div><br class=""></div></div></div>
</div>
_______________________________________________<br class="">RPD mailing list<br class=""><a href="mailto:RPD@afrinic.net" class="">RPD@afrinic.net</a><br class="">https://lists.afrinic.net/mailman/listinfo/rpd<br class=""></blockquote></div><br class=""></body></html>