BTW.Media
Daily editionStrategic Internet Intelligence
Sign InRegister

AFRINIC · RIR Watchdog

IPv4 Soft Landing – bis (Alain Aina)

Start here for the proposal-by-proposal record: what changed, why it mattered, who argued for what, how positions evolved, what was decided, and where the evidence still has gaps.

Source facts

Policy ID
AFPUB-2016-V4-001
RIR
AFRINIC
Official status
Under Discussion
Normalized status
Under discussion
Introduced
Feb 4, 2016
Last source update
Oct 1, 2026
Coverage
Partial

Who actually shaped the debate?

3Total participants
3Discussion contributors
UnknownFormal actors
5Discussion messages
2.8Effective participants
100%Top-five discussion share
2People covering 50%
2People covering 80%

Policy evolution

2.0
Under discussion · Under Discussion
Feb 4, 2016
Source facts ↗

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.

Source facts −
* Amends: AFPUB-2010-v4-005 (IPv4 soft landing policy) * Obsoletes : None
Source facts ↗
Source facts +
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
Source facts ↗

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.

Source facts −
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).
Source facts ↗
Source facts +
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.
Source facts ↗

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.

Source facts −
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.
Source facts ↗
Source facts +
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
Source facts ↗

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.

Source facts −
3.2 This policy proposal changes Clauses/Articles 3.6, 3.8 and 3.9 of the current IPv4 Soft Landing Policy
Source facts ↗
Source facts +
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
Source facts ↗

Debate timeline

  1. Introduced

    Introduced

    Source facts ↗

  2. Official version

    DRAFT-01

    Under discussion · Under Discussion

    Source facts ↗

  3. Official version

    2.0

    Under discussion · Under Discussion

    Source facts ↗

  4. Public discussion

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

    4 Discussion messages · 3 Entities

    Source facts ↗

Entities

Freshness: Stale
  1. John Hay · Identity unresolved
    Discussion messages2
    First activityAug 27, 2016
    Last activityAug 28, 2016
    First explicit stanceUnknown
    Latest explicit stanceUnknown
    Stance changes0
    Viewpoint consistencyConsistent
    Other policies0
  2. Owen DeLong
    Discussion messages2
    First activityFeb 3, 2016
    Last activityAug 25, 2016
    First explicit stanceOppose
    Latest explicit stanceOppose
    Stance changes0
    Viewpoint consistencyNo validated consistency assessment
    Other policies15
    Freshness: Stale

    Identity verified: Sep 11, 2026

    Hurricane Electric · Historical
    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

    Verified public profiles

    Discussion messages
    2
    First activity
    Feb 3, 2016
    Last activity
    Aug 25, 2016
    First explicit stance
    Oppose
    Latest explicit stance
    Oppose
    Stance changes
    0
    Viewpoint consistency
    No validated consistency assessment
    Other policies
    15

    First explicit stance: Oppose → Latest explicit stance: Oppose · Stance changes: 0

    Viewpoint consistency: No validated consistency assessment

    1. Feb 3, 2016 · Procedural or neutral

      [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.

      Source facts ↗
    2. Aug 25, 2016 · Oppose

      [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.

      Source facts ↗
    Per-policy stance timelines:AFPUB-2008-GEN-001 · Unknown · No explicit position statedAFPUB-2012-DNS-001 · Unknown · No explicit position statedAFPUB-2012-GEN-001 · Unknown · No explicit position statedAFPUB-2012-V4-001 · Unknown · No explicit position statedAFPUB-2013-GEN-001 · Unknown · No explicit position statedAFPUB-2013-V4-001 · Unknown · No explicit position statedAFPUB-2013-V4-002 · Unknown · No explicit position statedAFPUB-2013-V6-001 · Unknown · No explicit position statedafpub-2014-gen-002 · Support · No validated consistency assessmentAFPUB-2014-GEN-003 · Oppose · No validated consistency assessmentafpub-2014-gen-004 · Propose alternative · No validated consistency assessmentAFPUB-2014-GEN-005 · Unknown · No explicit position statedAFPUB-2016-GEN-001 · Support · No validated consistency assessmentAFPUB-2016-V4-001 · Oppose · No validated consistency assessmentAFPUB-2026-IPv4-001-DRAFT02 · Unknown · No explicit position statedService Level Agreement for the IANA Numbering Services · Unknown · No explicit position stated

    Total policy messages: 129

  3. S. Moonesamy
    Discussion messages1
    First activityAug 28, 2016
    Last activityAug 28, 2016
    First explicit stanceUnknown
    Latest explicit stanceUnknown
    Stance changes0
    Viewpoint consistencyInsufficient evidence to assess consistency
    Other policies9

Sources and coverage

Official policy sources

Public discussion archives

  • afrinic-rpd
    Earliest captured
    Aug 4, 2004
    Latest captured
    Aug 25, 2026
    Last refresh
    Oct 13, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    13,116
    Known gaps
    0
  • www.afrinic.net
  • afrinic-africann
    Earliest captured
    Aug 3, 2026
    Latest captured
    Oct 2, 2026
    Last refresh
    Oct 13, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    2,582
    Known gaps
    0
  • afrinic-afripv6-discuss
    Earliest captured
    Aug 17, 2015
    Latest captured
    Sep 18, 2026
    Last refresh
    Oct 13, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    2,538
    Known gaps
    0
  • afrinic-announce
    Earliest captured
    Aug 18, 2015
    Latest captured
    Sep 18, 2026
    Last refresh
    Oct 13, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    2,497
    Known gaps
    0
  • afrinic-community-discuss
    Earliest captured
    Sep 11, 2015
    Latest captured
    Dec 29, 2019
    Last refresh
    Oct 13, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    3,127
    Known gaps
    0
  • afrinic-dbwg
    Earliest captured
    Aug 4, 2026
    Latest captured
    Oct 6, 2026
    Last refresh
    Oct 13, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    926
    Known gaps
    0
  • afrinic-dnssec-ops
    Earliest captured
    Aug 18, 2015
    Latest captured
    Dec 1, 2016
    Last refresh
    Oct 13, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    307
    Known gaps
    0
  • afrinic-icp2-review
    Earliest captured
    Apr 10, 2025
    Latest captured
    Nov 10, 2025
    Last refresh
    Oct 13, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    0
    Known gaps
    0
  • afrinic-measurement-wg
    Earliest captured
    Feb 1, 2018
    Latest captured
    Nov 22, 2024
    Last refresh
    Oct 13, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    138
    Known gaps
    0
  • afrinic-mira
    Earliest captured
    Nov 17, 2020
    Latest captured
    Nov 22, 2024
    Last refresh
    Oct 13, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    0
    Known gaps
    0
  • afrinic-ois-wg
    Earliest captured
    Sep 9, 2021
    Latest captured
    Nov 22, 2024
    Last refresh
    Oct 13, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    0
    Known gaps
    0
  • afrinic-rpki-discuss
    Earliest captured
    Jan 15, 2016
    Latest captured
    Apr 23, 2026
    Last refresh
    Oct 13, 2026
    Coverage
    Source coverage is incomplete.
    Loading
    154
    Known gaps
    0

Coverage

Partial
Earliest captured: Aug 4, 2004
Latest captured: Oct 13, 2026

Freshness

Freshness: Stale · Last refresh:

Known gaps

  • www.afrinic.net: Source coverage is incomplete. · The source boundary has not yet been reached.
  • www.afrinic.net: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-rpd: Source coverage is incomplete. · The source boundary has not yet been reached.
  • www.afrinic.net: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-africann: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-afripv6-discuss: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-announce: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-community-discuss: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-dbwg: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-dnssec-ops: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-measurement-wg: Source coverage is incomplete. · The source boundary has not yet been reached.
  • afrinic-rpki-discuss: Source coverage is incomplete. · The source boundary has not yet been reached.