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

Wed Dec 20 09:04:35 UTC 2017

 Hi Owen,

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

Which timeline are you referring to?

> Such a distortion remains a disservice to the global internet community as well as a disservice to the African internet community as well.

Those who needed v4 were told long ago to apply for ressources  and many did before the softlanding was triggered. The last /8 is meant  for specific purpose as defined by the current soft landing.

Afrinic service region is the only one which approaches the  distribution  of the last v4 ressources in phases, taking into account  the specificities of the region.

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

Not exactly.

Providers who still need some v4 space now, will get  a /18 in phase 1 and  a  /22 in phase2 and give chance to others.

/18 (16 , 384 ) Pv4 addresses in the context of IPv4  exhaustion  is enough in majority of cases in this region

Kind regards

Marcus

________________________________
From: Omo Oaiya <Omo.Oaiya at wacren.net>
Sent: Wednesday, December 20, 2017 8:26:37 AM
To: Owen DeLong
Cc: AfriNIC RPD MList.
Subject: Re: [rpd] The need to review the existing soft landing policy (was Re: Two more petitioners)

On 19 Dec 2017, at 20:41, Owen DeLong <owen at delong.com<mailto:owen at delong.com>> wrote:

On Dec 19, 2017, at 10:29 , Omo Oaiya <Omo.Oaiya at wacren.net<mailto: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.

It seems to me that you have corroborated by statement.   Your personal opinions do not really matter here ….not your reference to the consensus of the global community to share equally as grotesque unfairness or your misguided attempt to twist the events to suit the reality you prefer.

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.

You need to read section 3 which anticipates hijacking of the intent of section 2.

3.  Rough consensus is achieved when all issues are addressed, but not necessarily accommodated

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.

Good luck.  Lets agree to differ.

Owen

My 0.02
Omo

1 - https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion/ipv4-available-pool-graph

On 19 Dec 2017 6:07 p.m., "Sander Steffann" <sander at steffann.nl<mailto: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<mailto:RPD at afrinic.net>
https://lists.afrinic.net/mailman/listinfo/rpd

_______________________________________________
RPD mailing list
RPD at afrinic.net<mailto:RPD at afrinic.net>
https://lists.afrinic.net/mailman/listinfo/rpd

------
Omo OAIYA
CTO/Directeur Technique
--------------------------------------------------------------------------------------------------------------------------------------------------
WACREN
m: +234 808 888 1571
e: omo.oaiya at wacren.net<mailto:omo.oaiya at wacren.net>

www.wacren.net<http://www.wacren.net>

[cid:00952C86-65AC-4232-9808-B0DABBB7FA80 at localdomain]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20171220/646cced3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WACREN_conference_2018_banner_600.png
Type: image/png
Size: 242502 bytes
Desc: WACREN_conference_2018_banner_600.png
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20171220/646cced3/attachment-0001.png>