What changed
No policy change can be identified from the supplied verified facts because the policy chronology is empty and no proposal text, revisions, milestones, or implementation record are provided.
RIPE NCC · RIR Watchdog
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
Who actually shaped the debate?
BTW Analysis
No policy change can be identified from the supplied verified facts because the policy chronology is empty and no proposal text, revisions, milestones, or implementation record are provided.
The subject of the debate cannot be determined from the supplied verified record. There are no messages, participant stance timelines, actor identities, or documented arguments.
Neither a discussion nor a decision outcome is established by the supplied facts. The extract records zero messages, zero discussion participants, zero formal actors, and zero active days, and it contains no vote, consensus determination, adoption, rejection, withdrawal, or implementation event. This evidentiary absence does not prove that no external process occurred.
The zero message shares, zero HHI, zero effective-participant count, and zero core-contributor counts describe an empty measured activity set, not broad, balanced, or equally distributed participation. No participation concentration or frequency distribution can be assessed because the extract contains zero messages and zero participants.
No procedural, institutional, or participant chokepoint can be identified from the supplied record. There is no chronology, decision-authority action, participant activity, or linkage between discussion and outcome from which control over policy progression could be inferred.
Larger replacement assignment for an IXP · Version 2 raises the proposed maximum replacement assignment from /23 to /22 when an IXP outgrows its default /24. The IXP must still return its current assignment, or existing PI space used for the peering LAN, and meet the stated 50% utilisation condition after one year unless special circumstances apply. The change enlarges the proposed growth allowance; it does not turn every existing IXP assignment into a /22.
New IXPs will be assigned a /24 by default. Should they require a larger assignment, they must return their current one (or existing PI used as an IXP peering LAN) and receive a replacement /23. After one year, utilisation of the new assignment must be at least 50%, unless special circumstances are defined.Source facts ↗
New IXPs will be assigned a /24 by default. Once they require a larger assignment, they must return their current one (or existing PI used as an IXP peering LAN) and receive a replacement up to maximum of a /22. After one year, utilisation of the new assignment must be at least 50%, unless special circumstances are defined.Source facts ↗
Availability threshold for smaller IXP assignments · Both drafts allow assignments down to /27 on request. Version 2 changes the alternative availability trigger from depletion of the reserved pool to the absence of available /24-or-larger assignments. This explicitly allows the smaller-block path when the pool still contains fragments but cannot supply a /24; the /27 option itself is not new in this version.
On request or upon depletion of the reserved pool, assignments down to a /27 can be made.Source facts ↗
On request or once there are no more assignments of /24 (or larger) available, assignments can be made down to /27.Source facts ↗
Routing returned addresses and small fragments into pools · Version 1 says that IPv4 space returned by IXPs goes to the reserved IXP pool. Version 2 adds a more specific recovery rule: space originally assigned by RIPE NCC exclusively for IXPs returns to that pool; other returned blocks of /24 or larger follow section 5.1, while smaller blocks enter the IXP reserve. This distinguishes the original purpose and size of a returned block rather than treating every return from an IXP identically.
Any IPv4 space returned by IXPs will be added to the reserved pool maintained for IXP use. Any assignments made previously from this pool will remain unchanged.Source facts ↗
Any IPv4 address space that was originally assigned by the RIPE NCC for exclusive use by Internet Exchange Points (IXPs) will be added to the reserved IXP pool upon return. Other address space blocks of a /24 or larger that are returned to the RIPE NCC will be covered by the same rules as the address space intended in section 5.1 – smaller blocks will be put into the reserved pool for IXP use.Source facts ↗
Loading
Partial
Earliest captured: Jun 30, 1992
Latest captured: Nov 12, 2026