[rpd] Questions for Alain...

Fri Jun 8 06:43:21 UTC 2018

Dear M. Stein,

Who should remove the policy?
Which section of PDP allow for removal of policy?

Le ven. 8 juin 2018 à 09:57, Saul Stein <saul at enetworks.co.za> a écrit :

> 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]
> *Sent:* 07 June 2018 07:43 PM
> *To:* 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> wrote:
>
>
>
>
>
>
>
> On Jun 6, 2018, at 06:34 , ALAIN AINA <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-transfer-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-soft-landing-sd
>
> (**)
> https://afrinic.net/en/library/policies/archive/withdrawn-proposals/1623-soft-landing-overhaul
>
>
>
> —Alain
>
>
>
>
>
> On 5 Jun 2018, at 10:29, Andrew Alston <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
>
>
>
> Andrew
>
>
>
> _______________________________________________
> 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
>

-- 
Borg le Chevalier
___________________________________
"Common sense is what tells us the world is flat"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20180608/9bc1facb/attachment-0001.html>