[rpd] The need to review the existing soft landing policy (was Re: Two more petitioners)

Wed Dec 20 06:58:42 UTC 2017

DeLong, usually you don't ask a committee to execute what is in you mind.
Rather the expectation is that the appeal committee hears  all sides with
their merits and fairly come to a conclusion. This way at the end the
committee would have seen to be equitable.

On Dec 19, 2017 9:46 PM, "Owen DeLong" <owen at delong.com> wrote:

>
> On Dec 19, 2017, at 10:29 , Omo Oaiya <Omo.Oaiya at wacren.net> wrote:
>
> Sander,
>
> 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.
>
> 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.
>
> 2 main differences in my mind:
>
> - 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)
>
> - 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.
>
>
> With all due respect, Omo, I think I fully appreciate the intent and
> spirit behind the allocation of the last /8.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
> 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.
>
> I will again quote from RFC 7282… The very header of section 2 sums it up
> quite well:
>
> 2 <https://tools.ietf.org/html/rfc7282#section-2>.  Lack of disagreement is more important than agreement
>
>
> 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.
>
> 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.
>
> Owen
>
>
> My 0.02
> Omo
>
> 1 - https://www.ripe.net/publications/ipv6-info-centre/about-ipv
> 6/ipv4-exhaustion/ipv4-available-pool-graph
>
>
> On 19 Dec 2017 6:07 p.m., "Sander Steffann" <sander at steffann.nl> wrote:
>
> Hi Alain,
>
> > 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.
>
> 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.
>
> 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.
>
> I encountered something similar in my own region. We had a policy proposal
> to slow down our version of the soft landing proposal:
> https://www.ripe.net/participate/policies/proposals/2017-03. 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.
>
> 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.
>
> Cheers,
> Sander
>
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> 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/20171220/d001bee9/attachment-0001.html>