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

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

Saul Stein saul at enetworks.co.za
Tue Dec 5 06:54:07 UTC 2017


Hi

Owen, thanks, you have responded and covered all my points



However: (I think that this goes off the topic at hand)



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.



If I am wrong, please correct me, but I think you have missed my point:

Getting resources from AFRINIC is considerably more expensive than the 
equivalent resources from RIPE for example, but in Africa, we have no choice 
but to get from AFRINIC – and luckily they still have v4 resources. That is 
a numbers game the more members you have, the less you can charge. At 
AFRINIC our membership fees are based on the size v4 space that we have. 
(rightly or wrongly, but that is not a debate for this thread). Thus the 
more space we have the more we pay. By preventing members getting space, we 
are preventing the financial resources of AFRINIC (as per current billing 
model). Thus if we all end up with more resources, AFRINICs revenue will 
increase. As a result, that could result in paying less fees.



Yes, I also do understand that if we have an outbound transfer policy, the 
above statement is moot as a large percentage of the space will be taken by 
the rest of the world.

Owen, please if I have missed something, happy to be corrected.





>Is there anything that stops forward looking network managers like yourself 
>from deploying v6 now?

Absolutely nothing, and that is why I have native v6 on my desktop and 
supply v6 transit to my customers.



From: Owen DeLong [mailto:owen at delong.com]
Sent: 05 December 2017 03:29 AM
To: Komi Elitcha <kmw.elitcha at gmail.com>
Cc: Saul Stein <saul at enetworks.co.za>; AfriNIC RPD MList. <rpd at afrinic.net>
Subject: Re: [rpd] FW: Opposition to the changes in the AfriNIC Soft Landing 
Policy





On Dec 4, 2017, at 17:06 , Komi Elitcha <kmw.elitcha at gmail.com 
<mailto: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:




 <https://tools.ietf.org/html/rfc7282#section-2> 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/20171205/d681e0a4/attachment-0001.html>


More information about the RPD mailing list