Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] FW: Opposition to the changes in the AfriNIC Soft Landing Policy

Owen DeLong owen at delong.com
Tue Dec 5 01:29:24 UTC 2017


> On Dec 4, 2017, at 17:06 , Komi Elitcha <kmw.elitcha at gmail.com> wrote:
> 
> Saul,
> 
> Le 4 déc. 2017 11:31, "Saul Stein" <saul at enetworks.co.za <mailto:saul at enetworks.co.za>> a écrit :
> Dear All,
> 
> I am seeing a large number or people who are against this policy. Far more than the 3 (if that) that have supported it. So I really do not see how and where the public consensus came from to pass this policy. The majority have spoken and are continuing to do so against this policy.
> 
>  
> 
> …there does seem to be a planned campaign.   Quite understandable for me.  It is the claim by some of the “multitude” that the Co-chairs did not follow process that is not quite clear to me.   

Komi,

Seems pretty straightforward to me.

Most of the sustained objections were not addressed and clearly remain (as evidenced by the “multitude” opposing the last call).

In the face of such objections, how can the co-chairs legitimately declare that consensus was reached.

Absent such consensus, last call is out of order according to the PDP.

Therefore, by either declaring a consensus which did not exist, or, by sending to last call without consensus, the Co-chairs failed in their duty and did not follow the process.

I hoe this clarifies things for you.

> 
> This policy proposal  has been discussed since February  2016 and has evolved a lot and address the main issues. So far there is no new major issues raised since this campaign started and this consolidates cochairs  decisions.

No, many of the core issues remain. It has not addressed the main issues despite repeated false claims that it has.

It has addressed some issues, but fundamentally, the core issues upon which Andrew and I base our objections remain a core intent of the proposal, so it is impossible to preserve the integrity of the proposal and address those issues.

> 
> RFC7282  sections 6 and 7 say:
> 
>  6.  One hundred people for and five people against might not be rough consensus
> 
> 7.  Five people for and one hundred people against might still be rough consensus

Sure. But it also states in section 2:

> 2 <https://tools.ietf.org/html/rfc7282#section-2>.  Lack of disagreement is more important than agreement
> 
>    A working group comes to a technical question of whether to use
>    format A or format B for a particular data structure.  The chair
>    notices that a number of experienced people think format A is a good
>    choice.  The chair asks on the mailing list, "Is everyone OK with
>    format A?"  Inevitably, a number of people object to format A for one
>    or another technical reason.  The chair then says, "It sounds like we
>    don't have consensus to use format A.  Is everyone OK with format B?"
>    This time even more people object to format B, on different technical
>    grounds.  The chair, not having agreement on either format A or
>    format B, is left perplexed, thinking the working group has
>    deadlocked.
> 
>    The problem that the chair got themselves into was thinking that what
>    they were searching for was agreement.  "After all", thinks the
>    chair, "consensus is a matter of getting everyone to agree, so asking
>    whether everyone agrees is what the chair ought to do.  And if lots
>    of people disagree, there's no consensus."  But _determining_
>    consensus and _coming to_ consensus are different things than
>    _having_ consensus.

We definitely have no lack of disagreement, so it is hard to imagine a situation
in which we could claim to have consensus.

Even rough consensus requires that all objections be addressed (though not necessarily
accommodated). While I suppose you could argue that dismissing our objections outright
constitutes addressing them, I really don’t think that’s what the IETF has in mind
and I think it’s a pretty flawed approach to policy development or rough consensus
in general.


>  
> 
> 
> Most of us are unable to be professional meeting attenders and often can’t afford the hours to spend away from our days jobs to follow online. Thus mailing lists offer us the time to catch-up after hours when we have time. Even so, again, where are all the supporters? We’re only seeing numerous people rejecting the proposal
> 
>  
> 
> As to the these signed documents that Andrew is sending, as one doesn’t need to be a member of AFRINIC to have a say in the RDP, so anyone call really have their say. As to the process and what has been discussed, the RPD isn’t the only mailing list and there have been a comments on local mailing lists.
> 
>  
> 
> The majority of people and real jobs (paid for by an employer) and don’t have the time to follow and read everything, but do talk to others and keep up to date with what is going in. Not to be able to receive more than a /18 now or a /22 in phase two in a two hear period, doesn’t take a rocket scientist to realise that it will kill any business and more importantly inhibit growth. It is well known, giving access to the internet, increases education, knowledge and quality of life thus reducing unemployment –all things that we really need to resolve in Africa. Why would any thinking person want to limit this?
> 
>  
> 
> We should not forget that the intent in soft-landing is transition to IPv6.  Or is IPv4 now the future?  

If that is your intent, then the policy is quite thoroughly flawed because this policy does absolutely nothing to facilitate or foster that transition. Instead, it creates an artificially long life for IPv4 at the cost of depriving existing networks of resources in order to dole out dribs and drabs of IPv4 resources to newcomers for decades to come. Such an approach is the very antithesis of your stated intent and is, in fact, a major reason for much of the opposition to this proposal.

> I heard the same folks saying IPv4 is dead/obsolete but now I am hearing we need IPv4.  

You don’t hear me saying I need more IPv4 resources, but I am saying that the need for IPv4 that some organizations have today is real and that the supposed need of organizations that won’t exist for decades on which this policy proposal is based is specious at best because the IPv6 transition will make it so unless we so utterly fail at the IPv6 transition that the internet becomes an unworkable, unusable conglomeration of overpriced IPv4 resources.

> One would expect that only laggards who don’t yet have real networks to run would be thinking of Phase 2 at this point. 

Quite the opposite, actually. Only laggards who don’t yet have real networks to run can possibly benefit from this proposal, while those with real networks to run today are faced with the very real possibility that phase 2 could be triggered very soon.

> The bottom line here is that this  shouldn’t have reached last call because of the lack unaddressed objections going back at least two years. It has been clear from the numerous objections that there is no consensus on this policy.
> 
> 
> Chairs, please think and hear what the community are saying and act accordingly. This is wasting large amounts for time that could be used in other areas!
> 
>  
> 
> Let’s sell the resource to members, AFRINIC can then either reduce all our fees (to get inline with the other RIRs) from the extra revenue they are making and we get on with v6 deployment
> 
>  
> 
> 
> Sell?   I am confused.  Is it about fees now?  No longer IPv4 obsolescence and IPv6 uptake?  Is there anything that stops forward looking network managers like yourself from deploying v6 now?

I think Saul’s statement reflects a somewhat limited understanding of the true relationship between AfriNIC and resource holders. I’m glad to see him speaking up and think we should encourage and educate him rather than ridicule some small aspect of ignorance he happens to display in the process.

Owen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20171204/ca599af7/attachment-0001.html>


More information about the RPD mailing list