AFRINIC · RIR-Beobachtung
IPv4 Resource Transfers within the AFRINIC region (AFPUB-2016-v4-003-DRAFT-01)
Beginnen Sie hier mit der Dokumentation zu jedem einzelnen Vorschlag: Was änderte sich, warum war dies von Bedeutung, wer argumentierte wofür, wie entwickelten sich die Positionen, was wurde beschlossen und wo weist die Beleglage noch Lücken auf?
Quellenbelegte Fakten
- Richtlinien-ID
- AFPUB-2016-V4-003
- RIR
- AFRINIC
- Offizieller Status
- Last Call
- Normalisierter Status
- Letzter Aufruf
- Eingebracht
- Unbekannt
- Letzte Quellenaktualisierung
- 01.10.2026
- Abdeckung
- Teilweise
Wer hat die Debatte tatsächlich geprägt?
Entwicklung der Richtlinie
Recipient qualification standard · Draft 2 replaces the broadly worded recipient membership/other-requirements clause with an explicit requirement to qualify for the transferred amount under the same standards as a direct AFRINIC allocation or assignment at the time of request. Membership remains required by the separate source-and-recipient clause.
Quellenbelegte Fakten −
3.2.2 The recipient must be a member of AFRINIC and must meet any other requirements defined by AFRINIC.Quellenbelegte Fakten ↗
Quellenbelegte Fakten +
3.4.2 The recipient must qualify for the amount of resources to be transferred by the same standards as would be applied to a request for an allocation or assignment directly from AFRINIC under current policies at the time of the request.Quellenbelegte Fakten ↗
Staff assessment of the activation trigger · The draft-2 snapshot adds staff concerns that tying activation to phase 2 of the soft-landing policy could become inapplicable if that policy changed or ceased to have a phase 2. These are assessment comments; draft 2 itself retains the phase-2 trigger.
Quellenbelegte Fakten −
3.1) This policy takes effect as from phase 2 of the IPv4 soft landing policy (AFPUB-2010-v4-005) or its successor.Quellenbelegte Fakten ↗
Quellenbelegte Fakten +
In 3.1 "This policy takes effect as from phase 2 of the IPv4 soft landing policy”. This proposal ties itself to the current soft landing policy - what if the soft-landing policy changes, is overhauled - or doesn’t have a phase 2 anymore?Quellenbelegte Fakten ↗
Staff assessment of prior transfers · New staff commentary identifies a possible distinction in the 12-month source restriction: its wording could permit a recent inbound inter-RIR recipient to transfer within AFRINIC while preventing a recent intra-AFRINIC recipient from doing so. The proposed restriction itself is retained; the commentary is not a newly enacted exception.
Quellenbelegte Fakten −
3.3.3 Source entities must not have received a transfer, allocation, or assignment of IPv4 number resources from AFRINIC for the 12 months prior to the approval of transfer request. This restriction excludes Mergers and Acquisitions transfers.Quellenbelegte Fakten ↗
Quellenbelegte Fakten +
In 3.3.3 - The current wording implies that the recipient of an inbound inter-RIR transfer in the past 12 months WOULD be allowed to make an outbound AFRINIC-to-AFRINIC transfer, while the recipient of an inbound AFRINIC-to-AFRINIC transfer in the past 12 months WOULD NOT be allowed to make an outbound AFRINIC-to-AFRINIC transfer.Quellenbelegte Fakten ↗
Staff request for a dispute definition · The draft-2 snapshot adds a request to define disputes and clarify how disputes involving the receiving organisation would affect a transfer. The underlying requirement that the source hold undisputed resources is retained. A staff request for clarification is not treated as a completed policy definition.
Quellenbelegte Fakten −
3.3.1 The source must be the current rightful holder of the IPv4 address resources recognised by AFRINIC, and not be involved in any dispute as to the status of those resources.Quellenbelegte Fakten ↗
Quellenbelegte Fakten +
On “Disputes” - define what shall be considered to be adispute. AFRINIC does not have a process/guideline at the moment about disputes. It is also not clearly mentioned if AFRINIC shall consider a transfer request if there are any disputes around the receiving organisation.Quellenbelegte Fakten ↗
Staff assessment of the need horizon · Added staff comments identify a mismatch between the draft's 12-month recipient need horizon and the cited soft-landing allocation period of eight months, suggesting alignment or deletion because current-policy qualification already applies. Draft 2 still contains the 12-month clause; the comments alone do not amend it.
Quellenbelegte Fakten −
3.2.4 Recipients must demonstrate the need for up to a 12-month supply of IPv4 address space.Quellenbelegte Fakten ↗
Quellenbelegte Fakten +
On “3.4.4“Recipients must demonstrate the need for up to a 12-month supply of IPv4 address space.”CPM - 5.4.5 states that the current allocation and assignment period of 12 months shall be changed to 8 months. Proposal 3.4.4 should be realigned with the allocation period that is in force at the time, or simply deleted because it's implied by the requirement for the recipient to qualify under current policies.Quellenbelegte Fakten ↗
Recorded page status · The retained draft-1 page is labelled Under Discussion and the draft-2 page Implemented. This is a difference between page metadata captured in the archive; it does not establish when implementation occurred or prove that draft 2 was implemented on its submission date.
Trigger and CPM integration · Draft 3 frames the proposal as new CPM article 5.7 and applies it to justified IPv4 needs AFRINIC cannot satisfy. It removes the dependency on reaching phase 2 of the soft-landing policy, expressly confirmed in its revision history.
Quellenbelegte Fakten −
3.1 This policy takes effect as from phase 2 of the IPv4 soft landing policy (AFPUB-2010-v4-005) or its successor.Quellenbelegte Fakten ↗
Quellenbelegte Fakten +
5.7.1 Summary of the policy This policy applies to an organization with justified need for IPv4 resources that cannot be satisfied by AFRINIC.Quellenbelegte Fakten ↗
Transfer-source eligibility · Draft 3 allows resources to come from either an existing AFRINIC member's account or a legacy holder in AFRINIC's service region. This expands the prior rule that both parties must be AFRINIC members. The recipient remains subject to a separate AFRINIC membership and RSA requirement.
Quellenbelegte Fakten −
3.2 Both the source entity and recipient must be AFRINIC members.Quellenbelegte Fakten ↗
Quellenbelegte Fakten +
5.7.2 IPv4 resources to be transferred must be from an existing AFRINIC member’s account or from a Legacy Resource Holder in the AFRINIC service region.Quellenbelegte Fakten ↗
Legacy status after transfer · Draft 3 explicitly states that transferred IPv4 legacy resources lose legacy status. The previous recipient conditions required current-policy compliance and an RSA but contained no corresponding legacy-status provision.
Quellenbelegte Fakten −
3.4.3 The recipient will be subject to current AFRINIC policies and sign the RSA for the resources being received.Quellenbelegte Fakten ↗
Quellenbelegte Fakten +
5.7.4.2 The recipient must be an AFRINIC member, subject to current AFRINIC policies and must sign the Registration Services Agreement for resources being received. 5.7.4.3 Transferred IPv4 legacy resources will no longer be regarded as legacy resources.Quellenbelegte Fakten ↗
Recipient need horizon · Draft 3 removes the standalone requirement to demonstrate up to a 12-month supply and explains that justification follows policies in force. It also removes the separate direct-allocation-equivalence sentence as already covered by the retained need-justification clause. These edits do not eliminate AFRINIC's approval of recipient need.
Quellenbelegte Fakten −
3.4.4 Recipients must demonstrate the need for up to a 12-month supply of IPv4 address space.Quellenbelegte Fakten ↗
Quellenbelegte Fakten +
* Removal of old 3.4.4; No need for the requirement on recipients of the transfer to demonstrate a need up to 12-month supply of IPv4 address space. Justification based on policies in force.Quellenbelegte Fakten ↗
Recorded page status · The draft-2 snapshot is labelled Implemented, while the draft-3 snapshot is labelled Last Call. These captured labels are retained as a metadata discrepancy; the comparison does not infer a reversal of implementation or overwrite the proposal's authoritative current status.
Zeitverlauf der Debatte
Entitäten
- Diskussionsbeiträge1Erste Aktivität04.02.2016Letzte Aktivität04.02.2016Erste ausdrückliche HaltungUnterstützung mit ÄnderungenLetzte ausdrückliche HaltungUnterstützung mit ÄnderungenHaltungswechsel0Konsistenz der PositionKeine validierte KonsistenzbewertungWeitere Richtlinien2Aktualität: Veraltet · Letzte Aktualisierung: · Die letzte Aktualisierung ist fehlgeschlagen. Das letzte erfolgreiche Ergebnis wird angezeigt.
Letzter Rechercheversuch: 13.10.2026
Identität verifiziert: 13.10.2026
Liquid Telecommunications · Historisch Andrew Alston, Liquid Telecommunications
ripe74.ripe.netVerifizierte öffentliche Profile
- Diskussionsbeiträge
- 1
- Erste Aktivität
- 04.02.2016
- Letzte Aktivität
- 04.02.2016
- Erste ausdrückliche Haltung
- Unterstützung mit Änderungen
- Letzte ausdrückliche Haltung
- Unterstützung mit Änderungen
- Haltungswechsel
- 0
- Konsistenz der Position
- Keine validierte Konsistenzbewertung
- Weitere Richtlinien
- 2
Erste ausdrückliche Haltung: Unterstützung mit Änderungen → Letzte ausdrückliche Haltung: Unterstützung mit Änderungen · Haltungswechsel: 0
Konsistenz der Position: Keine validierte Konsistenzbewertung
- 04.02.2016 · Unterstützung mit Änderungen
[rpd] Some thoughts, and some actions required
I have an issue with limiting transfers to intra-RIR for the following reasons … A.) We all know there is a massive shortage of space in Africa, so who is going to be selling what they need for critical business usage? No African company with half a braincell would sell space on the continent, because unlike elsewhere in the world, the allocations are already only just what people need … B.) The majority of legacy space and other huge allocations where a lot of the sales could come from exist outside the region, we need access to that … Let me be blunt, I?ve already started trying to figure out just how much space I may need to get on the secondary market post exhaustion, for planning purposes. If I?m right, there simply isn?t enough of it in Africa to accomplish this. I am VIOLENTLY opposed to African companies selling to outside entities, but I am also a realist and believe we may well end up having to buy from outside entities. … IP-V4 Exhaustion is unavoidable and as a community, we should handled this in a way that we continue to pursue the mission of our community: ?Work for the growth of Internet?. … This growth requires more nodes to be connected and than larger address space. To cater for this need (large address space), IP V6 has been defined. … * A transition period is needed to get this protocol widely adopted ( we are currently in) … * Lack of available IPV4 creates the secondary market as previously stated in this thread (this exists already). … According to what has been pointed out here, we as community shall do the following: … 1. Adopt a transfer policy to allow an official access to secondary market … I would agree to adopt In Region Transfer Policy, and apply a sanction (Withrawal of transferred ressources) of any form Inter-RIR transfer that would be done by a member. … This will allow African Region market to be regulated according to its environment. The cost of goods on a market depends on the need. Our current market needs are not the same with other Region and it won't be in our benefit to open this door. … 2. Strengthen allocation requirements: I fully support this.
Quellenbelegte Fakten ↗
Haltungsverläufe je Richtlinie:afpub-2014-gen-002 · Ablehnung · Keine validierte KonsistenzbewertungAFPUB-2014-GEN-005 · Alternativvorschlag · Keine validierte KonsistenzbewertungAFPUB-2016-V4-003 · Unterstützung mit Änderungen · Keine validierte KonsistenzbewertungRichtliniennachrichten insgesamt: 6
- RENU - Alain P. AINA · Identität ungeklärtDiskussionsbeiträge0Erste AktivitätUnbekanntLetzte AktivitätUnbekanntErste ausdrückliche HaltungUnbekanntLetzte ausdrückliche HaltungUnbekanntHaltungswechsel0Konsistenz der PositionKeine ausdrückliche Position angegebenWeitere Richtlinien0
- WACREN · Identität ungeklärtDiskussionsbeiträge0Erste AktivitätUnbekanntLetzte AktivitätUnbekanntErste ausdrückliche HaltungUnbekanntLetzte ausdrückliche HaltungUnbekanntHaltungswechsel0Konsistenz der PositionKeine ausdrückliche Position angegebenWeitere Richtlinien0
- NIC CIS - Nicholas Mbonimpa · Identität ungeklärtDiskussionsbeiträge0Erste AktivitätUnbekanntLetzte AktivitätUnbekanntErste ausdrückliche HaltungUnbekanntLetzte ausdrückliche HaltungUnbekanntHaltungswechsel0Konsistenz der PositionKeine ausdrückliche Position angegebenWeitere Richtlinien0
- Ali HADJI · Identität ungeklärtDiskussionsbeiträge0Erste AktivitätUnbekanntLetzte AktivitätUnbekanntErste ausdrückliche HaltungUnbekanntLetzte ausdrückliche HaltungUnbekanntHaltungswechsel0Konsistenz der PositionKeine ausdrückliche Position angegebenWeitere Richtlinien0
- Comores Telecoms - Komi ELITCHA - Damnam Kanlanfei BAGOLIBE - Serge Patrick GHANSAH-GNONKOTO · Identität ungeklärtDiskussionsbeiträge0Erste AktivitätUnbekanntLetzte AktivitätUnbekanntErste ausdrückliche HaltungUnbekanntLetzte ausdrückliche HaltungUnbekanntHaltungswechsel0Konsistenz der PositionKeine ausdrückliche Position angegebenWeitere Richtlinien0
- Comores Telecoms - Komi Elitcha - Damnam Kanlanfei BAGOLIBE - Patrick GH · Identität ungeklärtDiskussionsbeiträge0Erste AktivitätUnbekanntLetzte AktivitätUnbekanntErste ausdrückliche HaltungUnbekanntLetzte ausdrückliche HaltungUnbekanntHaltungswechsel0Konsistenz der PositionKeine ausdrückliche Position angegebenWeitere Richtlinien0
Quellen und Abdeckung
Offizielle Richtlinienquellen
Öffentliche Diskussionsarchive
- afrinic-rpd
- Früheste Erfassung
- 04.08.2004
- Letzte Erfassung
- 25.08.2026
- Letzte Aktualisierung
- 13.10.2026
- Abdeckung
- Die Quellenabdeckung ist unvollständig.
- Wird geladen
- 13.116
- Bekannte Lücken
- 0
- www.afrinic.net
- afrinic-africann
- Früheste Erfassung
- 03.08.2026
- Letzte Erfassung
- 02.10.2026
- Letzte Aktualisierung
- 13.10.2026
- Abdeckung
- Die Quellenabdeckung ist unvollständig.
- Wird geladen
- 2.581
- Bekannte Lücken
- 0
- afrinic-afripv6-discuss
- Früheste Erfassung
- 17.08.2015
- Letzte Erfassung
- 18.09.2026
- Letzte Aktualisierung
- 13.10.2026
- Abdeckung
- Die Quellenabdeckung ist unvollständig.
- Wird geladen
- 2.538
- Bekannte Lücken
- 0
- afrinic-announce
- Früheste Erfassung
- 18.08.2015
- Letzte Erfassung
- 18.09.2026
- Letzte Aktualisierung
- 13.10.2026
- Abdeckung
- Die Quellenabdeckung ist unvollständig.
- Wird geladen
- 2.497
- Bekannte Lücken
- 0
- afrinic-community-discuss
- Früheste Erfassung
- 11.09.2015
- Letzte Erfassung
- 29.12.2019
- Letzte Aktualisierung
- 13.10.2026
- Abdeckung
- Die Quellenabdeckung ist unvollständig.
- Wird geladen
- 3.127
- Bekannte Lücken
- 0
- afrinic-dbwg
- Früheste Erfassung
- 04.08.2026
- Letzte Erfassung
- 06.10.2026
- Letzte Aktualisierung
- 13.10.2026
- Abdeckung
- Die Quellenabdeckung ist unvollständig.
- Wird geladen
- 925
- Bekannte Lücken
- 0
- afrinic-dnssec-ops
- Früheste Erfassung
- 18.08.2015
- Letzte Erfassung
- 01.12.2016
- Letzte Aktualisierung
- 13.10.2026
- Abdeckung
- Die Quellenabdeckung ist unvollständig.
- Wird geladen
- 307
- Bekannte Lücken
- 0
- afrinic-icp2-review
- Früheste Erfassung
- 10.04.2025
- Letzte Erfassung
- 10.11.2025
- Letzte Aktualisierung
- 13.10.2026
- Abdeckung
- Die Quellenabdeckung ist unvollständig.
- Wird geladen
- 0
- Bekannte Lücken
- 0
- afrinic-measurement-wg
- Früheste Erfassung
- 01.02.2018
- Letzte Erfassung
- 22.11.2024
- Letzte Aktualisierung
- 13.10.2026
- Abdeckung
- Die Quellenabdeckung ist unvollständig.
- Wird geladen
- 138
- Bekannte Lücken
- 0
- afrinic-mira
- Früheste Erfassung
- 17.11.2020
- Letzte Erfassung
- 22.11.2024
- Letzte Aktualisierung
- 13.10.2026
- Abdeckung
- Die Quellenabdeckung ist unvollständig.
- Wird geladen
- 0
- Bekannte Lücken
- 0
- afrinic-ois-wg
- Früheste Erfassung
- 09.09.2021
- Letzte Erfassung
- 22.11.2024
- Letzte Aktualisierung
- 13.10.2026
- Abdeckung
- Die Quellenabdeckung ist unvollständig.
- Wird geladen
- 0
- Bekannte Lücken
- 0
- afrinic-rpki-discuss
- Früheste Erfassung
- 15.01.2016
- Letzte Erfassung
- 23.04.2026
- Letzte Aktualisierung
- 13.10.2026
- Abdeckung
- Die Quellenabdeckung ist unvollständig.
- Wird geladen
- 154
- Bekannte Lücken
- 0
Abdeckung
Teilweise
Früheste Erfassung: 04.08.2004
Letzte Erfassung: 13.10.2026
Aktualität
Bekannte Lücken
- www.afrinic.net: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
- www.afrinic.net: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
- afrinic-rpd: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
- www.afrinic.net: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
- afrinic-africann: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
- afrinic-afripv6-discuss: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
- afrinic-announce: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
- afrinic-community-discuss: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
- afrinic-dbwg: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
- afrinic-dnssec-ops: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
- afrinic-measurement-wg: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
- afrinic-rpki-discuss: Die Quellenabdeckung ist unvollständig. · Die Quellengrenze wurde noch nicht erreicht.
