AFRINIC · Мониторинг RIR
Здесь можно проследить судьбу каждого предложения: что изменилось, почему это было важно, кто и за что выступал, как менялись позиции, какое решение было принято и где в доказательной базе всё ещё остаются пробелы.
Факты из источников
Кто на самом деле определял ход дискуссии?
Аналитика BTW
Из предоставленных данных нельзя установить какие-либо изменения текста, статуса или направления политики: проверенная хронология и временные линии позиций пусты. Зафиксирован только измеренный срез с 0 сообщений, 0 участников, 0 формальных акторов и 0 активных дней.
Предмет и содержательные линии дебатов определить невозможно. В проверенных фактах отсутствуют сообщения, аргументы, позиции участников, переходы между позициями и нерешенные либо меньшинственные возражения.
Ни обсуждение, ни формальное решение не восстановлены. Нулевые показатели отражают отсутствие наблюдений в предоставленном срезе, но не доказывают отсутствие обсуждения вне его охвата. Данных о принятии, отклонении, отзыве, возврате на доработку, истечении срока или отсутствии решения нет.
Концентрация участия содержательно не оценивается. При 0 сообщениях и 0 участниках значения top-1, top-5, top-10, HHI и эффективного числа участников, равные 0, не свидетельствуют ни о широком распределении участия, ни о доминировании узкой группы; у показателей отсутствует ненулевая база наблюдений.
Процессуальный или институциональный узел контроля определить нельзя: данные не идентифицируют участников, формальных акторов, коалиции, органы решения или получателей дополнительного влияния. Единственный устанавливаемый аналитический барьер — нехватка доказательств: отсутствуют хронология версий, охваченные каналы, аргументы, записи формальных действий и итог решения.
Scope of the proposed transfer policy · The page titled Draft 3 defines recipients with justified IPv4 needs and sources with resources no longer needed. Its proposed scope no longer says AFRINIC must be unable to satisfy the need. The retained Current column still contains that older condition; it is not part of the proposed replacement.
5.7 IPv4 Resources transfers This policy applies to an organization with justified needs, for IPv4 resources that cannot be satisfied by AFRINIC.Факты из источников ↗
5.7 IPv4 Resources transfers This policy applies to an organization with a justified need for IPv4 resources (recipient) and organizations with IPv4 resources that are no longer needed by that organization (source).Факты из источников ↗
Validation of the transfer source · Draft 3 explicitly assigns validation to the source RIR under its own policies and procedures. For AFRINIC sources it additionally specifies good standing, rightful registration and no resource-status dispute. Draft 2 instead states a general rightful-holder and no-dispute condition for the relevant RIR.
5.7.2.1 The source must be the current rightful holder of the IPv4 address resources in the relevant RIR, and not be involved in any dispute as to the status of those resources.Факты из источников ↗
5.7.2.1 A source must be validated by the applicable source RIR according to their policies and procedures. A source within AFRINIC must be in good standing, be the rightful registrant of the resources to be transferred and there must be no disputes as to the status of said resources.Факты из источников ↗
Receiving resources after an outbound transfer · Draft 3 adds an explicit route for a source organisation to receive resources by transfer after at least 24 months from its last outbound transfer, subject to justified need. The prohibition on further AFRINIC allocations or assignments remains; inbound transfers are distinguished from those pool allocations.
5.7.2.2 Source entities will not be eligible to receive any further IPv4 address allocations or assignments from AFRINIC.Факты из источников ↗
5.7.2.2 Source entities will not be eligible to receive any further IPv4 address allocations or assignments from AFRINIC. Source entities may, if they can show justified need, receive resources via transfer after a period of not less than 24 months has elapsed from their last outbound transfer.Факты из источников ↗
Recipient approval and membership wording · Draft 3 specifies the same policies and procedures as an AFRINIC-pool request for AFRINIC recipients, and the receiving RIR's rules for other recipients. It removes the separate proposed clause requiring membership and legal/service agreements. That deletion does not establish an exemption from membership or agreements imposed by the applicable RIR's own rules.
5.7.3.3 The recipient must be a member of the relevant RIR, subjected to its policies and legal documents/service agreements.Факты из источников ↗
5.7.3.1 Recipient organizations within the AFRINIC service region must be approved with the same policies and procedures as if the request were being satisfied from the AFRINIC pool. 5.7.3.2 Recipients in other RIRs must be approved according to that RIR’s policies and procedures.Факты из источников ↗
Legacy status on outbound transfers · Draft 3 explicitly leaves the resulting status of outgoing inter-RIR resources to the receiving RIR's policies. Both drafts remove legacy status for intra-RIR transfers and transfers incoming to AFRINIC; the new sentence clarifies the previously unstated outbound case.
5.7.3.4 IPv4 legacy resources will no longer be regarded as legacy resources: * In the case of intra-RIR transfers. * In the case of inter-RIR, when incoming to AFRINIC service region.Факты из источников ↗
In the case of outgoing inter-RIR transfers, the resulting status will depend on the policies in the receiving RIR.Факты из источников ↗
Transfer disclosure wording · Draft 3 replaces automatic publication of non-confidential information on a specific web page with AFRINIC publishing related information permitted by the source or recipient. Both retain minimum details covering date, resources and the organisations and RIRs on each side. The revision changes the disclosure formulation without deleting those listed minimum fields.
5.7.6 Transparency of Transfers Each time a transfer is completed, the relevant, non-confidential information will be automatically published in a specific web page, including at least: Date of the transfer, transferred resources, source organization and RIR, destination organization and RIR.Факты из источников ↗
5.7.6 Required Disclosure for Transfers Each time a transfer is completed, AFRINIC will publish all related information permitted by the source or recipient, including at least: * Date of the transfer. * Transferred resources. * Source RIR and organization * Recipient RIR and organization.Факты из источников ↗
Handling a suspicious transfer · Draft 3 says staff may request additional information and then must escalate all available information to the board for an approval decision. It removes Draft 2's explicit power in this clause to provisionally suspend a suspicious operation. The separate six-consecutive-month outbound imbalance suspension remains unchanged in substance.
5.7.8.2 The staff can provisionally suspend any suspicious operation and request more information to all the parties, so the board can take a decision.Факты из источников ↗
5.7.7.2 Staff may request additional information from parties for any transfer deemed suspicious by staff. Afterwards, all available information shall be escalated to the board for a decision to approve the transfer or not.Факты из источников ↗
Eligibility after an outbound transfer · The proposed wait before a source can receive resources by transfer changes from at least 24 months to at least 16 months, linked to twice the window in CPM 5.4.5. Both texts separately exclude further allocations or assignments from AFRINIC.
Source entities may, if they can show justified need, receive resources via transfer after a period of not less than 24 months has elapsed from their last outbound transfer.Факты из источников ↗
5.7.2.2 Source entities will not be eligible to receive any further IPv4 address allocations or assignments from AFRINIC. Source entities may, if they can show justified need, receive resources via transfer after a period of not less than 16 months (twice the window defined by 5.4.5) has elapsed from their last outbound transfer.Факты из источников ↗
Recent receipt from the AFRINIC pool · The proposed restriction on becoming a transfer source after receiving IPv4 resources from AFRINIC changes from the preceding 12 months to 16 months. The comparison uses the proposed column, not the retained current-policy text alongside it.
5.7.2.3 An organization which has received IPv4 resources from AFRINIC within the preceding 12 months will not be approved as a transfer source.Факты из источников ↗
5.7.2.3 An organization which has received IPv4 resources from AFRINIC within preceding 16 months will not be approved as a transfer source.Факты из источников ↗
Associated ASN transfers · Draft 4 makes an ASN transfer discretionary for AFRINIC and ties it to more than 50% of the IPv4 resources associated with that ASN being transferred. The earlier page instead allows relevant ASNs with a majority of IPv4 resources, subject to relevant policies.
5.7.4 Transfer of ASN with IPv4 Resources In the case where the majority of the IPv4 resources are being transferred, any relevant ASN(s) may also be transferred at the same time, if the relevant policies are fulfilled.Факты из источников ↗
5.7.4 Transfer of ASN with IPv4 Resources At the AFRINIC discretion, in the case where over 50% of the IPv4 resources associated with an ASN are being transferred, that ASN may also be transferred at the same time.Факты из источников ↗
Phase-2 activation condition · The earlier proposed text expressly makes inter-RIR transfers start only at Exhaustion Phase 2. Draft 4 removes that timing clause and renumbers disclosure as 5.7.5. This is a change to proposed wording, not evidence that inter-RIR transfers were implemented.
5.7.5 Timing for Applicability of Inter-RIR transfers Inter-RIR transfers will be triggered only once AFRINIC enters Exhaustion Phase 2 (as defined in CPM 5.4.3.2).Факты из источников ↗
5.7.5 Required Disclosure for Transfers Each time a transfer is completed, AFRINIC will publish all related information permitted by the source or recipient, including at least:Факты из источников ↗
Disclosure under inter-RIR agreements · Draft 4 expressly preserves publication of the same or other information under operating agreements among RIRs, in addition to its transfer-disclosure list.
5.7.6 Required Disclosure for Transfers Each time a transfer is completed, AFRINIC will publish all related information permitted by the source or recipient, including at least:Факты из источников ↗
This doesn’t exclude the publication of the same or other information as a result of the operating agreement among the RIRs.Факты из источников ↗
Staff assessment of merger scope · The Draft 4 page adds a staff assessment requesting clarification because its policy clauses do not explicitly address mergers and acquisitions. The earlier proposal's two transfer types do not themselves settle that question. This is staff commentary, not an additional operative condition.
5.7.1 Recognized transfer types Two types of transfers are recognized: a) Intra-RIR. Both parties are within the AFRINIC service region. b) Inter-RIR. One of the parties is within the AFRINIC service region, while the other is in the service region of another RIR.Факты из источников ↗
Since the policy text does not explicitly mention that resources can be transferred as a result of mergers and acquisitions, staff assume that this policy proposal excludes transfers of IPv4 addresses due to mergers and acquisitions. Author's input is required in this case.Факты из источников ↗
Conflicting earlier version metadata · The earlier retained page is headed Draft 3 but repeats a DRAFT01 identifier, while the later page consistently identifies Draft 4. The comparison binds these exact source texts; it does not silently resolve the earlier metadata conflict or describe this as a verified Draft 1-to-4 sequence.
AFPUB-2019-IPV4-002-DRAFT01: IPv4 Inter-RIR Resource Transfers (Comprehensive Scope) Draft 3 | ArchivedФакты из источников ↗
AFPUB-2019-IPV4-002-DRAFT04: IPv4 Inter-RIR Resource Transfers (Comprehensive Scope) Draft-4 | ArchivedФакты из источников ↗
Express exclusion of mergers and acquisitions · Draft 5 adds an explicit statement in the proposal explanation that mergers and acquisitions are outside its scope. Draft 4's staff assessment had requested clarification on that point.
Since the policy text does not explicitly mention that resources can be transferred as a result of mergers and acquisitions, staff assume that this policy proposal excludes transfers of IPv4 addresses due to mergers and acquisitions. Author's input is required in this case.Факты из источников ↗
This proposal is not covering M&A, which is already being discussed in another proposal.Факты из источников ↗
ASN transfer provision removed · Draft 5 removes the proposed ASN-with-IPv4 transfer provision. Its revision history says ASN transfers will be addressed in a separate proposal; this does not establish whether any separate proposal was adopted.
5.7.4 Transfer of ASN with IPv4 Resources At the AFRINIC discretion, in the case where over 50% of the IPv4 resources associated with an ASN are being transferred, that ASN may also be transferred at the same time.Факты из источников ↗
Removed text on ASN transfers, which will be a different proposal, so to concentrate on the most urgent problem by nowФакты из источников ↗
Suspension and suspicious-transfer clauses removed · Draft 5 removes both the six-month outward-versus-inward suspension trigger and the suspicious-transfer referral to the Board. Its history explains the authors' view that existing Board powers suffice; that explanation is not an independent finding about legal powers.
5.7.6.1 The inter-RIR transfers will be suspended in case the number of outgoing IPv4 addresses exceeds the incoming ones for 6 consecutive months. 5.7.6.2 Staff may request additional information from parties for any transfer deemed suspicious by staff. Afterwards, all available information shall be escalated to the board for a decision to approve the transfer or not.Факты из источников ↗
Removed suspensions, as the board is already able to make that without the need of this text, and community discussion proved that they are no longer worried about this.Факты из источников ↗
Availability of a version-specific staff assessment · The retained Draft 4 page includes an August 2020 assessment. The Draft 5 page only promises a future staff assessment. The missing assessment must not be read as withdrawal of the earlier concerns or approval of the revised proposal.
AFRINIC Staff Assessment Date of Assessment Relevant to Proposal Aug 2020 AFPUB-2019-IPv4-002-DRAFT04Факты из источников ↗
Explicit source holdings · Draft 6's proposed clauses explicitly identify resources held in an RIR member account or by a legacy holder across AFRINIC and other RIR regions. Draft 5 describes eligible sources generally; the comparison does not treat this wording as evidence of an implemented transfer.
5.7 IPv4 Resources transfers This policy applies to an organization with a justified need for IPv4 resources (recipients) and organizations with IPv4 resources which no longer need (sources).Факты из источников ↗
The resources to be transferred must be from an existing RIR member’s account or from a Legacy Resource Holder in the AFRINIC service region/other RIRs.Факты из источников ↗
Resource-use pre-check · Draft 6 adds a mandatory AFRINIC pre-check when the transfer source is a resource member, verifying allocation or assignment and use against the RSA/CPM. Draft 5 contains the source's good-standing and registration conditions but no separate pre-check clause.
5.7.2.1 A source must be validated by the applicable source RIR according to their policies and procedures. A source within AFRINIC must be in good standing, be the rightful registrant of the resources to be transferred and there must be no disputes as to the status of said resources.Факты из источников ↗
5.7.5 Transfers pre-check Where the source of the transfer is a resource member, AFRINIC will run a pre-check to verify if the resources being transferred were allocated/assigned and used according to the RSA/CPM. The member has to pass the pre-check.Факты из источников ↗
Protection following recipient-side failure · Draft 6 allows a passed transfer pre-check to remain valid for up to 12 months after a transfer fails because of recipient noncompliance, and says AFRINIC will not begin recovery or reclamation in that period. This is a new proposed protection, not a finding about an existing entitlement.
5.7.2.1 A source must be validated by the applicable source RIR according to their policies and procedures.Факты из источников ↗
This proposal allows the successful transfer pre-check to be valid for up to 12 months after the failed transfer; i.e AFRINIC will not initiate a recovery/reclamation process in this period. 4. ReferencesФакты из источников ↗
Staff concerns about the pre-check protection · Draft 6 includes a dated staff assessment warning that its interpretation of the protection could prevent reviews or audits for 12 months, and requesting clarity about recovery after a failed pre-check. These are staff concerns; the operative clause itself expressly refers to recovery or reclamation.
This policy states that after a successful transfer pre-check AFRINIC can’t perform any reviews and audits on this member for a period of 12 months; this can be dangerous as members can decide to violate RSA/CPM within this time without consequences. In case of pre-check failure, can the author clarify if AFRINIC can take the resources back as the member is not compliantФакты из источников ↗
Historical implementation and reciprocity assessment · Unlike Draft 5's assessment placeholder, Draft 6's staff assessment gives Q4 2022 as its earliest implementation estimate and leaves reciprocity to be confirmed. These are the captured historical assessment's statements, not evidence of implementation or present compatibility.
4.0) Implementation The earliest we can implement the same will be in Q4 2022 based on the updated plan. 5.0) Reciprocity with the other RIRs To be confirmedФакты из источников ↗
Merger exclusion in operative clauses · Draft 6 places the exclusion of both inter- and intra-region mergers and acquisitions in the proposed transfer-types clause. Draft 5 states its M&A exclusion in explanatory text.
This proposal is not covering M&A, which is already being discussed in another proposal.Факты из источников ↗
Mergers and acquisitions (inter or intra) are not covered by this policy.Факты из источников ↗
Eligibility wording broadens from organisations to entities · Draft 7 uses entities rather than organisations and describes the source as a resource holder, including legacy holders. Its revision history explains that this avoids excluding parties that are not juridical persons. This changes the proposed transfer scope; it does not establish that the proposal was adopted.
This policy applies to an organization with a justified need for IPv4 resources (recipients) and organizations with IPv4 resources which no longer need (sources).Факты из источников ↗
This policy applies to any entity with a justified need for IPv4 resources (recipients) and entities with IPv4 resources which no longer need (sources).Факты из источников ↗
Explicit membership and RSA requirements for inbound recipients · Draft 7 expressly requires a recipient that is not yet an AFRINIC member to sign the RSA and complete membership procedures. The transferred resources would then fall under RSA and CPM terms. Draft 6 applies the ordinary pool-approval policies without this explicit new-member wording.
5.7.3.1 Recipient organizations within the AFRINIC service region must be approved with the same policies and procedures as if the request were being satisfied from the AFRINIC pool.Факты из источников ↗
If the recipient is not yet an AFRINIC member, it will need to sign the RSA and fulfil all the relevant processes to become a member, and consequently, the resources being the subject matter of the transfer will then be covered by the RSA and CPM terms.Факты из источников ↗
Pre-check failure and continuing responsibility during the grace period · Draft 7 ties source pre-checks to section 5.7.2.1 and expressly subjects a failed pre-check to RSA/CPM terms. It also states that the retained twelve-month validity of a successful pre-check does not protect new violations during that period. Draft 6 contains the grace period without these express qualifications.
Where the source of the transfer is a resource member, AFRINIC will run a pre-check to verify if the resources being transferred were allocated/assigned and used according to the RSA/CPM. The member has to pass the pre-check.Факты из источников ↗
The validity of the pre-check doesn’t limit the RSA/CPM terms in case of further policy violations during the 12 months period (i.e., new CPM or RSA violations).Факты из источников ↗
Due diligence becomes an express proposed obligation · Draft 7 adds section 5.7.6, assigning due diligence to the source holder and recipient and describing AFRINIC as a facilitator without legal responsibility in that process. Draft 6 presents that allocation of responsibility as a legal-assessment recommendation. This records proposed wording, not a conclusion that liability can lawfully be excluded.
To address this issue, it is proposed that the burden of conducting such adequate due diligence be placed on both the source holder and the intended recipient, and that AFRINIC’s role should be limited to acting as a facilitator only without bearing any legal responsibility whatsoever in that process.Факты из источников ↗
5.7.6 Due diligence Both the source holder and recipient will be responsible for conducting adequate due diligence with respect to the concerned IPv4 number resources. AFRINIC’s role is limited to acting as a facilitator only, without bearing any legal responsibility whatsoever in that process.Факты из источников ↗
Reciprocity assessment now names all four other RIRs · The Draft 6 assessment leaves reciprocity to be confirmed. The Draft 7 assessment records compatibility or reciprocity with APNIC, ARIN, LACNIC and RIPE NCC. These are assessment statements about the proposed text, not evidence that transfers were activated.
5.0 Reciprocity with the other RIRs APNIC - This version of the proposal is Fully reciprocal and bi-directional ARIN - Draft 7 of this proposal represents a reciprocal, compatible needs-based policy, and as such is compatible with the ARIN Inter-RIR transfer policy. LACNIC - Compatible with LACNIC Inter-RIR policies RIPE NCC - Compatible with RIPE NCC policyФакты из источников ↗
Updated assessment still requests clarification · The assessment changes from 27 October to 12 November 2021. It still questions twelve-month pre-check validity and failed-pre-check recovery despite the new operative qualifications. Its legal section also repeats questions addressed by new due-diligence and RSA wording. These unresolved or stale assessment passages must remain distinct from the actual Draft 7 clauses; they are not an approval.
this can be dangerous as members can decide to violate RSA/CPM within this time without consequences.Факты из источников ↗
The author is requested to clarify the reasoning behind 'validity of pre-checks is 12 monthsФакты из источников ↗
Данные из источников собраны не полностью.
Частично
Самая ранняя фиксация: 4 авг. 2004 г.
Последний снимок: 12 окт. 2026 г.