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

[rpd] [Spam] Re: Questions for Alain...

Saul Stein saul at enetworks.co.za
Sun Jun 17 18:38:56 UTC 2018


Marcus,

If you wish to disagree with something that I have said or done, you are
most welcome. However, I do expect a level civility and dignity.

I am not going to engage in a mudslinging to and fro with you or comment
on aspects of your email, or as Badru calls it, the school playground, but
please don’t make baseless pointless challenges and instantiated remarks.



I shall not with draw my request. I have read the views that people’s
motives should not have any bearing on the reasons for writing policies.
Sadly, we don’t live in a utopic world and this policy has brought our
community to be the laughing stock of the industry.



I know full well that the chairs can’t withdraw a policy. However, while I
understand the dangers of the next sentence, I do think that maybe we
should consider such powers – if a policy can do to the community what
this one has done, then there should be a way to stop it.



Saul





From: Marcus K. G. Adomey [mailto:madomey at hotmail.com]
Sent: 16 June 2018 10:05 PM
To: ALAIN AINA <aalain at trstech.net>; rpd at afrinic.net; Saul Stein
<saul at enetworks.co.za>
Subject: [Spam] Re: [rpd] Questions for Alain...



Hi Saul,



Your emails to Alain and to the PDPWG co-chairs raised some issues worth
pointing out to you.



First of all, almost all of us are doing our best to promote the best for
this  <http://community.  Your> community. Your inconsiderate instruction
to Alain to withdraw soft-landing bis proposal is rude and uncalled for.
Regardless the clarification brought to you by some members of the
community on the conflict of interest which is neither here nor there
landed on a dead rock and you went ahead to issue another instruction the
co-chairs to withdraw the soft-landing bis and as you can see, it went
nowhere. Just another unnecessary and useless assaults on people
contributing to make things better, which you may not like. Your failure
to follow governing principles and show respect to people is unacceptable.



After all, I expected cochairs to remind you the basic governing
principles and prevent this from happening again.



I also give you 24h to render an unqualified apology for your
inappropriate actions, time for you to show minimum level of civility.



While then, enjoy your evening





Marcus

  _____

From: Saul Stein < <mailto:saul at enetworks.co.za> saul at enetworks.co.za>
Sent: Friday, June 8, 2018 5:55:00 AM
To: ALAIN AINA;  <mailto:rpd at afrinic.net> rpd at afrinic.net
Subject: Re: [rpd] Questions for Alain...



Chairs,



It has been more than 24hours since my last request.

Alain has not withdrawn this policy. He has acknowledged that he wasn’t a
broker at the time of compilation of the policy, but now is and a clear
conflict arises.



Please can this policy be removed due to conflict of interest.



From: ALAIN AINA [ <mailto:aalain at trstech.net> mailto:aalain at trstech.net]
Sent: 07 June 2018 07:43 PM
To:  <mailto:rpd at afrinic.net> rpd at afrinic.net
Subject: Re: [rpd] Questions for Alain...



Owen,



I did not know in 2016 that I will be associated to an ip broker project.
I am sorry that my "African magic" was  not sufficient to predict this
future.



The intra-RIR policy was adopted by the community and implemented by
AFRINIC. Hence, one would expect Brokers to emerge on the continent.



Let me repeat:



The original proposal of SL-bis did not contain any limitation beyond the
change on the max allocation size in phase 1.



The revision history of the proposal is very explicit on the changes. The
limitations proposed by Sl-SD team were incorporated into the SL-BIS
after the Nairobi meeting based on discussions at the PPM and on list
after the PPM. PPM minutes and RPD archives are available to prove that.



Policy proposals evolve beyond the control of the initiators.



So, let us not redo the SL-bis discussions on the same issues again, and
let us move forward.



Thanks



—Alain



On 6 Jun 2018, at 18:48, Owen DeLong <owen at delong.com
<mailto:owen at delong.com> > wrote:







On Jun 6, 2018, at 06:34 , ALAIN AINA <aalain at trstech.net
<mailto:aalain at trstech.net> > wrote:





Hi Andrew,



I know that the SL-BIS policy proposal still giving you insomnia, but
relax.



It is bizarre that i co-authored the SL-bis since February 2016 and the
Intra-RIR v4 transfer proposal, the 23rd may 2016 and you did not see the
so-called conflict.



Considering that it was not known at that time that you intended to be a
broker (at least not to Andrew, nor myself), why is it bizarre?



Both elements must be known in order to become aware of the conflict.



Now back to your point, i don't see how the SL-bis proposal submitted in
February 2016 creates a v4 shortage.  It was about  "fair distribution of
the last /8 of v4 and IPv6 deployment”:



Laughable.



It was about preventing those who need address space now from getting it
(i.e. an artificial shortage) in order to have some available for those
who do not yet need it but might in the future.



It has nothing to do with fairness. It’s ostensibly all about keeping a
free pool available as long as possible for speculative possible future
needs. The only way you can achieve that is by creating an artificial
shortage (or, more accurately, artificially worsening the existing
shortage) for those that need address space now.





How does it solve the problem
[https://afrinic.net/en/library/policies/archive/1609-soft-landing-bis]

========

2) Summary of How this Proposal Addresses the Problem

This policy proposal solves the problem described above by:



Changing the value of the maximum allocation/assignment size during the
exhaustion phase 1.

Imposing IPv6 resources as a pre-condition to IPv4 resource requests
during the exhaustion.

Reserving address spaces for Critical Internet Infrastructure and new LIRs
or End-Users.

Removing the minimum allocation size as this may evolve over time during
the exhaustion period.



You left out the part where you create a maximum amount of space per unit
of time restriction on applicants.



That provision (which is part of the policy) is the most controversial and
also the most critical to the real intents behind the proposal (denying
space to those who need it now to support the ostensible goal of providing
it to others later).



There are those that argue that such a denial is “fair” and there are
those who argue that it is completely unfair.





=====



and the proposal itself is clear:



-No explicit limit on the number of times an organization may request
additional IPv4 address space during Exhaustion Phases(same as the soft
landing policy implemented)



Except that there is
 There’s a limit on the amount of space an
organization may receive within a given time period which is effectively
the same thing.





We all know how it evolved and how the SL-SD(*) proposal came in and
impacted the original proposal.



The Intra-RiR proposal was meant to address justified needs after
exhaustion of Afrinic pool or when AFRINIC cant no longer satisfied such
needs. It reached consensus (there was no  appeal filled against) and has
been implemented..
[https://www.afrinic.net/en/library/policies/archive/1785-ipv4-resources-t
ransfer-within-the-afrinic-region]



====

2) Summary of How this Proposal Addresses the Problem

The Policy solves the issue of an African organisation needing IPv4 number
resources after the exhaustion of the AFRINIC IPv4 pool or when AFRINIC
can no longer satisfy the needs of such an organization.

=======



So, overall fair distribution from the last /8 and other remaining blocks
and provisions to cover justified needs inside the region after AFRINIC
pool exhaustion.



Where is this problem ?



You were accused with your proposal of soft-landing-overhaul(**) to fast
track the exhaustion of the AFRINIC pool(distribute the  last /8 with the
max  allocation size at /10 instead of the /13 as per current soft landing
policy or  /15 proposed by SL-bis proposal ) and i should have followed
you if i was acting to promote a v4 market.



Actually, not really. Preserving effective shortage against large
providers while still facilitating small providers obtaining sufficient
IPv4 to be able to avoid IPv6 provides the maximum revenue opportunity for
brokers while also being maximally destructive to the progress of a free
and open internet. SL-BIS does exactly this.



Fast tracking run-out, OTOH, brings AfriNIC in line with the rest of the
world and helps get everyone moving towards IPV6 sooner rather than later,
thus allowing those who have implemented IPv6 to deprecate their IPv4
albatrosses sooner rather than later, thus allowing the entire internet to
move forward sooner rather than later.



True, it hurts the following parties:

            CGN vendors because it reduces demand for costly CGN solutions

            Those in denial about IPv6 because it forces them into an
uncomfortable reality check.

            Brokers because it reduces the peak value and lifetime of the
IPv4 marketplace

            Those sitting on large unused IPv4 pools for the same reasons
as brokers.

            Those late to the party who still think they can pursue an
IPv4-only strategy for a new business.

            Those late to the party who find it expensive to support
remaining IPv4-only customers.



However, it would be better for the internet overall and would create a
greater level of pain for a much shorter period of time vs. SL-BIS which
seeks to intensify the pain more gradually while prolonging the duration
of that pain and achieving a much higher maximum.



If you believe that SL-BIS actually provides fair distribution or
otherwise solves the IPv4 runout problem, then you are like the
mythological frog in the pot of water.



The myth says that if you toss a frog in to a pot of hot water, it will
jump out and save itself. It goes on to say that if you put the frog in a
pot of cold water and slowly bring it to a boil, the frog will not notice
and will be boiled to death without reacting.



Turns out that frogs are smarter than the myth would have us believe and
do leave when the temperature becomes uncomfortable, regardless of how
slowly the temperature rises.



IPv4 runout is like the water. The rise in temperature is inevitable.
SL-BIS will make the rise in temperature slower, and its supporters hope
we won’t notice and will continue to sit in the water as we get scalded.
SL-SD would rapidly heat the water and provide a clear signal that it
would be best for us all to get out of the IPv4 pot and use IPv6.



Hope this clarifies and helps the discussions.



While it is a nice set of obfuscations, I think the community will still
see through the deception and continue to oppose SL-BIS as it has been
doing for a few years now.



Owen







(*)
https://afrinic.net/en/library/policies/archive/withdrawn-proposals/2089-s
oft-landing-sd

(**)
https://afrinic.net/en/library/policies/archive/withdrawn-proposals/1623-s
oft-landing-overhaul



—Alain





On 5 Jun 2018, at 10:29, Andrew Alston <Andrew.Alston at liquidtelecom.com
<mailto:Andrew.Alston at liquidtelecom.com> > wrote:



Alain,



You have actively supported and fought for the new soft landing policy –
to artificially restrict space to entities that need it.



Now, I’d like to ask – as an author of the soft-landing-bis policy which
you have STILL not withdrawn
 aren’t you just a LITTLE bit conflicted in
trying to create an artificial shortage and make it hard for people to get
space – while starting and founding an IP broker in Africa?



Maybe now we understand the *true* motivations behind the soft landing bis
policy
.



 <http://ext-host.trstech.net/ipregistrar/trust_us.html>
http://ext-host.trstech.net/ipregistrar/trust_us.html



Andrew



_______________________________________________
RPD mailing list
 <mailto:RPD at afrinic.net> RPD at afrinic.net
 <https://lists.afrinic.net/mailman/listinfo/rpd>
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





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


More information about the RPD mailing list