BTW.Media
Édition du jourVeille stratégique Internet
ConnexionS'inscrire

AFRINIC · Veille des RIR

IPv4 Soft Landing – bis (Alain Aina)

Commencez ici pour consulter l’historique, proposition par proposition : ce qui a changé, pourquoi cela comptait, qui a défendu quoi, comment les positions ont évolué, ce qui a été décidé et quelles lacunes subsistent dans les preuves.

Faits sourcés

Identifiant
AFPUB-2016-V4-001
RIR
AFRINIC
Statut officiel
Under Discussion
Statut normalisé
En discussion
Introduction
4 févr. 2016
Dernière mise à jour des sources
1 oct. 2026
Couverture
Partielle

Qui a réellement façonné le débat ?

4Total des participants
4Contributeurs à la discussion
InconnueActeurs formels
6Messages de discussion
3,6Entités effectives
100 %Part des cinq premiers
2Personnes couvrant 50 %
3Personnes couvrant 80 %

Évolution de la politique

2.0
En discussion · Under Discussion
4 févr. 2016
Faits sourcés ↗

From selective amendments to a replacement proposal · Draft 1 amended selected clauses of the existing IPv4 Soft Landing Policy and explicitly obsoleted none. Draft 2 presents a complete replacement of section 3 and says it would obsolete that existing policy. Its restated provisions must therefore be read as a complete proposal; this change in drafting scope is not evidence that the proposal was adopted or that every restated rule was newly introduced.

Faits sourcés −
* Amends: AFPUB-2010-v4-005 (IPv4 soft landing policy) * Obsoletes : None
Faits sourcés ↗
Faits sourcés +
16th Feb 2016 AFPUB-2016-V4-001-DRAFT02 (version 2.0) Posted to the rpd mailing list. A complete new version of the section 3 and so the policy proposal now obsoletes the existing IPv4 soft landing policy instead of amending it. Change of the title for clarity
Faits sourcés ↗

New-entrant eligibility is explicitly tied to exhaustion · Draft 1 described the new-entrant reserve as available to new LIRs or end users with no prior AFRINIC IPv4 space. Draft 2 additionally defines a new LIR by whether it had received IPv4 space before the exhaustion phase, while retaining the reserve's no-prior-space condition. The two formulations need to be read together: the definition does not itself prove that an organisation which has already received an allocation may draw again from the new-entrant reserve.

Faits sourcés −
3.9.2 Allocations/Assignments to new LIRs or End-Users A /14 from the final /11 will be held in reserve for exclusive use by new LIRs or End-Users with no prior IPv4 address space from AFRINIC. On application for IPv4 resources, a new LIR or End-User may receive one number resource (maximum /22).
Faits sourcés ↗
Faits sourcés +
New LIR - A New LIR, is a LIR that assigns address space to 'end-users' and is a member of AFRINIC, but has not been allocated any IPv4 address space prior to the Exhaustion phase.
Faits sourcés ↗

Repeat-request wording extends beyond phase 1 · Draft 1 confined its statement of no explicit limit on repeated requests to exhaustion phase 1. Draft 2 uses the broader term Exhaustion Period and expressly adds a one-allocation limit for critical infrastructure using its reserved pool in phase 2, alongside the existing new-entrant restriction. The broad sentence does not erase those specific reserve limits. Draft 2's unfinished opening sentence in section 3.6 leaves a drafting ambiguity that the retained text alone cannot resolve.

Faits sourcés −
3.6 If any LIR or End User requests IPv4 address space during Exhaustion: There is no explicit limit on the number of times an organization may request additional IPv4 address space during Exhaustion Phase 1. During exhaustion Phase 2, new LIRs or End-Users can receive only one allocation/assignment from the new LIRs or End-Users reserved pool.
Faits sourcés ↗
Faits sourcés +
During exhaustion Phase 2, new LIRs or End-Users can receive only one allocation/assignment from the new LIRs or End-Users reserved pool. During exhaustion Phase 2, Critical Infrastructure can receive only one allocation/assignment from the Critical Internet Infrastructure reserved pool. There is no explicit limit on the number of times an organization may request additional IPv4 address space during the Exhaustion Period
Faits sourcés ↗

Eight-month planning period becomes explicit in the complete text · Draft 2 explicitly includes an eight-month allocation and assignment planning period throughout the policy's life, describing a reduction from twelve months. Draft 1's amendment list did not reproduce section 3.7. This comparison establishes that the rule is now explicit in the replacement draft, but cannot by itself establish that the eight-month rule was absent from the pre-existing policy which Draft 1 would have left partly in force.

Faits sourcés −
3.2 This policy proposal changes Clauses/Articles 3.6, 3.8 and 3.9 of the current IPv4 Soft Landing Policy
Faits sourcés ↗
Faits sourcés +
3.7) The current allocation and assignment period of 12 months shall be changed to 8 months. The current allocation and assignment period of 12 months shall be changed to 8 months. This will help to ensure that LIRs request only for resources they need in the short to medium term, and promote fairness in the equitable distribution of the last IPv4 address pool. This allocation/assignment period will remain the same throughout the life span of this Policy
Faits sourcés ↗

Chronologie du débat

  1. Présentation

    Présentation

    Faits sourcés ↗

  2. Version officielle

    DRAFT-01

    En discussion · Under Discussion

    Faits sourcés ↗

  3. Version officielle

    2.0

    En discussion · Under Discussion

    Faits sourcés ↗

  4. Débat public

    [rpd] Policy Proposal Update - IPv4 Soft Landing-bis

    4 Messages de discussion · 3 Entités

    Faits sourcés ↗

Entités

Actualité: Périmé
  1. John Hay · Identité non résolue
    Messages de discussion2
    Première activité27 août 2016
    Dernière activité28 août 2016
    Première position expliciteInconnue
    Dernière position expliciteInconnue
    Changements de position0
    Cohérence du point de vueCohérent
    Autres politiques0
  2. Owen DeLong
    Messages de discussion2
    Première activité3 févr. 2016
    Dernière activité25 août 2016
    Première position expliciteOpposition
    Dernière position expliciteOpposition
    Changements de position0
    Cohérence du point de vueAucune évaluation de cohérence validée
    Autres politiques15
    Actualité: Périmé

    Identité vérifiée: 11 sept. 2026

    Hurricane Electric · Historique
    Owen Delong, (Hurricane Electric) stated that the RFC2050 is one of the IETF documents that delegates the number policies and processes to the to RIR system.
    www.ripe.net

    Profils publics vérifiés

    Messages de discussion
    2
    Première activité
    3 févr. 2016
    Dernière activité
    25 août 2016
    Première position explicite
    Opposition
    Dernière position explicite
    Opposition
    Changements de position
    0
    Cohérence du point de vue
    Aucune évaluation de cohérence validée
    Autres politiques
    15

    Première position explicite: Opposition → Dernière position explicite: Opposition · Changements de position: 0

    Cohérence du point de vue: Aucune évaluation de cohérence validée

    1. 3 févr. 2016 · Procédural ou neutre

      [rpd] Some thoughts, and some actions required

      Unless I misunderstand the AfriNIC RPD process, if we do not come to consensus on a policy in June, there cannot be a policy until at least 6 months later when the next AfriNIC meeting occurs. … As Andrew has shown that runout will very likely occur in the time between those two meetings, I think that depending on existing stockpiles of addresses to get everyone through the time to develop a policy at the following meeting is rather short-sighted and perilous. … If the community as a whole decides that running out with a resounding thud and taking an approach of too-bad-so-sad, all expansion must now be IPv6, then I don?t really have a problem with that decision. I think it will be a difficult decision for many to live with, but who knows, perhaps it will give IPv6 a nice kick into high gear and everything will turn out OK after all. … What I would hate to see is for the community to stick their collective head in the sand and refuse to consider the consequences of such a decision allowing it to occur passively and without forethought and deliberation. … The soft landing policy isn?t a workaround as it stands. I?m not sure that minor modification will turn it into one. However, if you care to expand on what minor changes you believe will provide such a remedy, I think the community would give them the appropriate consideration.

      Faits sourcés ↗
    2. 25 août 2016 · Opposition

      [rpd] Policy Proposal Update - IPv4 Soft Landing-bis

      Shortchanging more people in order to keep IPv4 space in the free pool longer is not helping anyone. … If there is a justified need for the resources, then the RIR should distribute them accordingly. When there are no more resources to distribute, the RIR should record appropriate transfers as the community sees fit to permit in policy. … Beyond that, the RIR has very little (no?) role in artificially extending the life of IPv4 by creating more shortages for more people while a free pool continues to exist.

      Faits sourcés ↗
    Chronologies des positions par politique:AFPUB-2008-GEN-001 · Inconnue · Aucune position explicite n’a été énoncéeAFPUB-2012-DNS-001 · Inconnue · Aucune position explicite n’a été énoncéeAFPUB-2012-GEN-001 · Inconnue · Aucune position explicite n’a été énoncéeAFPUB-2012-V4-001 · Inconnue · Aucune position explicite n’a été énoncéeAFPUB-2013-GEN-001 · Inconnue · Aucune position explicite n’a été énoncéeAFPUB-2013-V4-001 · Inconnue · Aucune position explicite n’a été énoncéeAFPUB-2013-V4-002 · Inconnue · Aucune position explicite n’a été énoncéeAFPUB-2013-V6-001 · Inconnue · Aucune position explicite n’a été énoncéeafpub-2014-gen-002 · Soutien · Aucune évaluation de cohérence validéeAFPUB-2014-GEN-003 · Opposition · Aucune évaluation de cohérence validéeafpub-2014-gen-004 · Proposition alternative · Aucune évaluation de cohérence validéeAFPUB-2014-GEN-005 · Inconnue · Aucune position explicite n’a été énoncéeAFPUB-2016-GEN-001 · Soutien · Aucune évaluation de cohérence validéeAFPUB-2016-V4-001 · Opposition · Aucune évaluation de cohérence validéeAFPUB-2026-IPv4-001-DRAFT02 · Inconnue · Aucune position explicite n’a été énoncéeService Level Agreement for the IANA Numbering Services · Inconnue · Aucune position explicite n’a été énoncée

    Messages de politique: 170

  3. Jackson Muthili · Identité non résolue
    Messages de discussion1
    Première activité16 juin 2017
    Dernière activité16 juin 2017
    Première position expliciteSoutien avec modifications
    Dernière position expliciteSoutien avec modifications
    Changements de position0
    Cohérence du point de vueÉléments insuffisants pour évaluer la cohérence
    Autres politiques7
  4. S. Moonesamy
    Messages de discussion1
    Première activité28 août 2016
    Dernière activité28 août 2016
    Première position expliciteInconnue
    Dernière position expliciteInconnue
    Changements de position0
    Cohérence du point de vueÉléments insuffisants pour évaluer la cohérence
    Autres politiques9

Sources et couverture

Sources officielles

Archives des discussions publiques

  • afrinic-rpd
    Première capture
    4 août 2004
    Dernière capture
    25 août 2026
    Dernière actualisation
    14 oct. 2026
    Couverture
    La couverture de la source est incomplète.
    Chargement
    13 116
    Lacunes connues
    0
  • www.afrinic.net
  • afrinic-africann
    Première capture
    3 août 2026
    Dernière capture
    2 oct. 2026
    Dernière actualisation
    14 oct. 2026
    Couverture
    La couverture de la source est incomplète.
    Chargement
    2 617
    Lacunes connues
    0
  • afrinic-afripv6-discuss
    Première capture
    17 août 2015
    Dernière capture
    18 sept. 2026
    Dernière actualisation
    14 oct. 2026
    Couverture
    La couverture de la source est incomplète.
    Chargement
    2 538
    Lacunes connues
    0
  • afrinic-announce
    Première capture
    18 août 2015
    Dernière capture
    18 sept. 2026
    Dernière actualisation
    14 oct. 2026
    Couverture
    La couverture de la source est incomplète.
    Chargement
    2 497
    Lacunes connues
    0
  • afrinic-community-discuss
    Première capture
    11 sept. 2015
    Dernière capture
    29 déc. 2019
    Dernière actualisation
    14 oct. 2026
    Couverture
    La couverture de la source est incomplète.
    Chargement
    3 127
    Lacunes connues
    0
  • afrinic-dbwg
    Première capture
    4 août 2026
    Dernière capture
    6 oct. 2026
    Dernière actualisation
    14 oct. 2026
    Couverture
    La couverture de la source est incomplète.
    Chargement
    959
    Lacunes connues
    0
  • afrinic-dnssec-ops
    Première capture
    18 août 2015
    Dernière capture
    1 déc. 2016
    Dernière actualisation
    14 oct. 2026
    Couverture
    La couverture de la source est incomplète.
    Chargement
    307
    Lacunes connues
    0
  • afrinic-icp2-review
    Première capture
    10 avr. 2025
    Dernière capture
    10 nov. 2025
    Dernière actualisation
    14 oct. 2026
    Couverture
    La couverture de la source est incomplète.
    Chargement
    0
    Lacunes connues
    0
  • afrinic-measurement-wg
    Première capture
    1 févr. 2018
    Dernière capture
    22 nov. 2024
    Dernière actualisation
    14 oct. 2026
    Couverture
    La couverture de la source est incomplète.
    Chargement
    138
    Lacunes connues
    0
  • afrinic-mira
    Première capture
    17 nov. 2020
    Dernière capture
    22 nov. 2024
    Dernière actualisation
    14 oct. 2026
    Couverture
    La couverture de la source est incomplète.
    Chargement
    0
    Lacunes connues
    0
  • afrinic-ois-wg
    Première capture
    9 sept. 2021
    Dernière capture
    22 nov. 2024
    Dernière actualisation
    14 oct. 2026
    Couverture
    La couverture de la source est incomplète.
    Chargement
    0
    Lacunes connues
    0
  • afrinic-rpki-discuss
    Première capture
    15 janv. 2016
    Dernière capture
    23 avr. 2026
    Dernière actualisation
    14 oct. 2026
    Couverture
    La couverture de la source est incomplète.
    Chargement
    154
    Lacunes connues
    0

Couverture

Partielle
Première capture: 4 août 2004
Dernière capture: 14 oct. 2026

Actualité

Actualité: Périmé · Dernière actualisation:

Lacunes connues

  • www.afrinic.net: La couverture de la source est incomplète. · La limite de la source n’a pas encore été atteinte.
  • www.afrinic.net: La couverture de la source est incomplète. · La limite de la source n’a pas encore été atteinte.
  • afrinic-rpd: La couverture de la source est incomplète. · La limite de la source n’a pas encore été atteinte.
  • www.afrinic.net: La couverture de la source est incomplète. · La limite de la source n’a pas encore été atteinte.
  • afrinic-africann: La couverture de la source est incomplète. · La limite de la source n’a pas encore été atteinte.
  • afrinic-afripv6-discuss: La couverture de la source est incomplète. · La limite de la source n’a pas encore été atteinte.
  • afrinic-announce: La couverture de la source est incomplète. · La limite de la source n’a pas encore été atteinte.
  • afrinic-community-discuss: La couverture de la source est incomplète. · La limite de la source n’a pas encore été atteinte.
  • afrinic-dbwg: La couverture de la source est incomplète. · La limite de la source n’a pas encore été atteinte.
  • afrinic-dnssec-ops: La couverture de la source est incomplète. · La limite de la source n’a pas encore été atteinte.
  • afrinic-measurement-wg: La couverture de la source est incomplète. · La limite de la source n’a pas encore été atteinte.
  • afrinic-rpki-discuss: La couverture de la source est incomplète. · La limite de la source n’a pas encore été atteinte.