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

[rpd] IPv4 Soft Landing-bis Statement Post AFRINIC-26

herve.clement at orange.com herve.clement at orange.com
Fri Jun 16 15:37:20 UTC 2017


+1 with the « an organization that has received the maximum allowable prefix in each phase may request for another round of allocation/assignment in the same phase after a 24 calendar months waiting period.” addition



Best regards



Hervé CLEMENT

De : Maye Diop [mailto:mayediop at gmail.com]
Envoyé : vendredi 16 juin 2017 11:51
À : John Ngwoke
Cc : rpd List
Objet : Re: [rpd] IPv4 Soft Landing-bis Statement Post AFRINIC-26

Dear All,
I fully support the following proposal.
Best Regards
====|
an organization that has received the maximum allowable prefix in each
phase may request for another round of allocation/assignment in the
same phase after a 24 calendar months waiting period.
|=====

2017-06-16 9:39 GMT+00:00 John Ngwoke <john.ngwoke at unn.edu.ng<mailto:john.ngwoke at unn.edu.ng>>:
====|
an organization that has received the maximum allowable prefix in each
phase may request for another round of allocation/assignment in the
same phase after a 24 calendar months waiting period.
|=====

+1


On Fri, Jun 16, 2017 at 10:28 AM, Lydea Akiriza <akirizal at gmail.com<mailto:akirizal at gmail.com>> wrote:
Another +1!

On 16 Jun 2017 12:20 pm, "Noah" <noah at neo.co.tz<mailto:noah at neo.co.tz>> wrote:


On 16 Jun 2017 9:13 a.m., "Jackson Muthili" <jacksonmuthi at gmail.com<mailto:jacksonmuthi at gmail.com>> wrote:
The proposal IPv4 Soft Landing BIS only needs one more input to make it perfect.

That input should come from the just withdrawn Soft Landing SD as follows:

====|
an organization that has received the maximum allowable prefix in each
phase may request for another round of allocation/assignment in the
same phase after a 24 calendar months waiting period.
|=====

With this addition it has my full support (also add the /24 minimum back).

Due to urgency of need of this proposal to cap abusers with negative
interests of our region depleting our pool and hence negating fair and
equitable distribution of this last block I request that co-chairs
immediately vary the process for quick approval of this proposal
(BIS-SD or whatever both parties will call it)

+1 jackson


J


On Fri, Jun 16, 2017 at 8:24 AM, Omo Oaiya <Omo.Oaiya at wacren.net<mailto:Omo.Oaiya at wacren.net>> wrote:
> Dear Community,
>
> On 9 February 2016, we initiated a policy proposal to update the IPv4 Soft
> Landing policy (SL) adopted in 2011 and which followed the Global IPv4 soft
> landing policy that granted the 102/8 to AFRINIC in February 2011
>
> The existing Soft landing policy defines how to fairly distribute the 102/8
> and other remaining v4 space to support a smooth transition to IPv6.  It
> defines 2 phases (phase 1 and Phase 2) and keep a reserve of /12 for
> unforeseen future. More detail at
> http://www.afrinic.net/library/policies/1829-afrinic-consolidated-policy-manual#SoftLanding
>
> The IPv4 Softlanding-Bis (SL-Bis) proposal aimed to make the distribution
> more equitable based on AFRINIC IPv4 allocation/assignment statistics. It
> stayed in the spirit of the Soft Landing policy (Need based allocations,
> fair distribution, no limit on request from members) with the following
> changes:
>
> - reduce the max allocation/assignment in phase 1 from /13 to  /18 ([latest
> version]
>
> - change nothing in Phase 2
>
> - remove the minimum allocation of /24 and empower staff to determine the
> minimum as we go through the exhaustion and the transition to IPv6
>
> - cancel the unforeseen future reserve(to be used at BoD discretion) and
> create a dedicated reserve  for IPv6 deployment[ latest version] :
>
> - allocation/assignment to root ops and  African ccTLDs operating in the
> region for dual stack  DNS servers
>
> - v4 space for new comers with IPv6 network for 464XLAT/ transition
> mechanisms
>
> More information on the SL-Bis proposal at
> https://www.afrinic.net/en/community/policy-development/policy-proposals/2075-ipv4-soft-landing-bis
>
> On 12 February 2016,  a policy proposal named “Soft Landing
> Overhaul”(SL-overhaul) was submitted. Section 2.0 of the proposal reads
>
> ======
>
> 2.0 Summary of How this Proposal Addresses the Problem
>
> This proposal still maintains a block of space reserved for new entrants,
> but beyond that, it allows for the natural depletion of IPv4 through
> standard demand, and hence encourages the uptake of IPv6 in a more
> aggressive manner.
>
> =====
>
> More information on SL-overhaul at
> https://www.afrinic.net/en/library/policies/archive/withdrawn-proposals/1623-soft-landing-overhaul
>
> The two proposals were presented at AFRINIC24 held in Gaborone (June 2016).
> Despite the fact that many participants supported SL-Bis proposal, the
> chairs declared that none of the 2 proposals got consensus.
>
> During AFRINIC-25 held in Mauritius (November 2016), to avoid the Gaborone
> scenario, the authors of SL-Bis offered to work together with the authors of
> SL-overhaul to find a common ground about how to update the SL policy
> despite the differences in the problem statements of the two proposals.
>
> SL-overhaul authors withdrew their proposal thereafter and the consolidation
> attempts by the Co-chairs produced the following document
> -https://goo.gl/AWCCWd
>
> The Chairs called for volunteers to take on points from that document and
> propose policy while SL-bis was still in the PDP track.  As a consequence,
>
> Soft Landing SD (SL-SD) was proposed on 30th March 2017. Section 2.0 of the
> proposal reads:
>
>  =======
>
> 2. Summary of how this proposal addresses the problem
>
> This proposal tries to address these problems by:
>
>   - Reducing the maximum prefix in phase 1. We arrived at this figure by
> looking at the average allocation prefix. We found the average to be between
> /17 and /16.
>
>   -  Disallowing allocation to organisations who have been allocated up to
> the maximum prefixes during each phase for certain duration.
>
>   - Adjusted the maximum prefix for phase 2, to bring it closer to average
> allocation size.
>
> =========
>
> The proposal modifies section 5.4.4 of the CPM to the following:
>
> ==============
>
> For any LIR or End User requesting IPv4 address space during the Exhaustion
> phases:
>
> 5.4.4.1 An organization may request additional IPv4 address space in both
> Phase 1 and Phase 2. However, such an organisation's total
> allocations/assignments must not exceed the maximum allowable prefix of /16
> for Exhaustion Phase 1 and /20 for Exhaustion Phase 2.
>
> 5.4.4.2 Notwithstanding 5.4.4.1, an organisation that has received the
> maximum allowable prefix in each phase may request for another round of
> allocation/assignment in the same phase (as per 5.4.4.1), after 24 calendar
> months waiting period.
>
> =====================
>
> More information about SL-SD at
> https://www.afrinic.net/en/library/policies/archive/withdrawn-proposals/2089-soft-landing-sd
>
> SL-BIS and SL-SD were presented at AFRINIC26 held in Nairobi (May 2017). As
> in Gaborone, the chairs declared no consensus for the 2 proposals despite
> the overwhelming support for SL-BIS.  The SL-SD team withdrew their proposal
> which only got support from author present.. See withdrawal message at
> https://lists.afrinic.net/pipermail/rpd/2017/006924.html
>
> Some discussions have occurred on the list after the AFRINIC26 meeting about
> consolidating Soft landing policy update around SL-bis, etc…
>
> In conclusion, if the chairs got the message from the community and are
> ready to vary the PDP as per section 3.6 of the CPM, the authors will
> happily work on submitting an update of SL-bis.  Otherwise, the authors
> consider that based on the timing of the exhaustion phases and current PDP
> process, we have reached a juncture at which a further update has diminished
> value. As such, we would find it more productive to work separately on
> aspects of the Soft landing that do not have time constraints and can still
> go through the normal PDP.
>
> The authors thank you all for your contribution and support all along the
> SL-bis journey.
>
>
> Joe Kimaili (Ubuntunet Alliance) Alain Aina, Omo Oaiya (WACREN)
>
>
>
> _______________________________________________
> 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


_______________________________________________
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



--
 ---------------------------------------------------------------
John C. Ngwoke (JP)
Head, Network section
ICT
University of Nigeria
Nsukka 410001
web: http://www.unn.edu.ng<http://www.unn.edu.ng/>
Mobile: +2348035723901<tel:+234%20803%20572%203901>, +23407017059403<tel:+234%20701%20705%209403>
Skype:  john.ngwoke

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



--
---------------------
Mme Ndéye Maimouna DIOP
Spécialiste ICT4D

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

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


More information about the RPD mailing list