Ce qui a changé
Aucun changement de politique ne peut être établi. La chronologie vérifiée est vide et aucune version, modification textuelle ou étape procédurale n’est fournie.
RIPE NCC · Veille des RIR
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
Qui a réellement façonné le débat ?
Analyse BTW
Aucun changement de politique ne peut être établi. La chronologie vérifiée est vide et aucune version, modification textuelle ou étape procédurale n’est fournie.
L’objet réel du débat est indéterminé : aucun message, argument, participant exprimant une position ou élément chronologique vérifié n’est disponible.
Ni la discussion ni la décision ne peuvent être reconstituées. Les compteurs nuls ne permettent de conclure ni à une adoption, ni à un rejet, ni à un retrait, ni à un abandon, ni à une absence de consensus.
L’extraction contient zéro message et zéro participant. Les parts top-1, top-5 et top-10, le HHI et le nombre effectif de participants, tous égaux à zéro, sont donc non informatifs : ils ne démontrent ni une participation équilibrée ni une concentration du débat.
Aucun point de blocage ou acteur exerçant un contrôle déterminant ne peut être identifié. Il n’existe dans les faits fournis ni activité observée, ni acteur formel, ni noyau de contributeurs, ni transition de position, ni événement procédural permettant de localiser un chokepoint.
Exhaustion trigger based on a /22 equivalent · Version 1 starts the waiting list when a single /22 can no longer be allocated. Version 2 instead uses the point at which an equivalent of a /22 can no longer be allocated, while retaining the preceding section's ability to assemble that total from more than one block. This distinguishes exhaustion of a contiguous /22 from exhaustion of the aggregate amount available for an allocation. Both versions then use a /24 waiting-list allocation size.
In case an allocation of a single /22 as per clause 1 can no longer be made, the RIPE NCC will start allocating IPv4 resources based on a first-come-first-serve waiting list.Faits sourcés ↗
Once an equivalent of a /22 can no longer be allocated, the RIPE NCC will start allocating IPv4 resources based on a first-come-first-served waiting list.Faits sourcés ↗
Small-fragment holding rule before the waiting list · Version 2 keeps section 5.1 and adds an explicit rule holding blocks smaller than /24 until missing fragments are recovered. Version 1 instead stops the ordinary allocation phase when a single /22 cannot be supplied; its stated rationale avoids handing an LIR fragmented blocks. The new /24 floor accompanies the move to a /22-equivalent exhaustion trigger. Both drafts separately retain a holding rule for fragments below the allocation size in the waiting-list phase.
To prevent allocating the last /22s from multiple smaller fragments, this proposal starts the waiting list scheme as soon as no contiguous /22 can be allocated anymore. This prevents LIRs from receiving fragmented blocks (which they would need to announce separately in the BGP routing table).Faits sourcés ↗
Keep existing text of 5.1 and add: All address blocks smaller than a /24 will be held by the RIPE NCC and are declared unallocatable until the missing fragments are received/recovered by the RIPE NCC.Faits sourcés ↗
Waiting-list assignment confirmation and contiguous block wording · Version 2 omits the separate sentence in version 1's waiting-list section requiring the LIR to confirm that it will make assignments from the allocation. It also explicitly says that, if a single /24 cannot be supplied, allocation waits until contiguous /24s are available again. The omission is specific to this proposed waiting-list wording; it does not demonstrate that all assignment obligations elsewhere in the policy disappear.
Once this allocation limit has been reached or exceeded an LIR can not request any further IPv4 resources under this policy. The LIR must confirm it will make assignment(s) from the allocation. In case an allocation of a single /24 as per clause 1 can no longer be made, no allocation is to be made until the RIPE NCC recovers enough address space to allocate contiguous allocations again.Faits sourcés ↗
If this allocation limit has been reached or exceeded, an LIR cannot request an IPv4 allocation under this policy. In case an allocation of a single /24 as per clause 1 can no longer be made, no allocation is to be made until the RIPE NCC recovers enough address space to allocate contiguous /24 allocations again.Faits sourcés ↗
Narrower declared scope of the second draft · Version 2 explicitly narrows the proposal's stated focus to creating a /24 waiting list after the existing allocation policy can no longer operate, and says the other proposed changes have been removed. Version 1's summary had also described removing the special treatment of the 14 September 2012 date. This is a change in the authors' explanation of scope: version 1's operative text already contained a /22 phase, so its summary should not be read as an immediate /24-only rule.
This policy proposal changes the allocation size to a /24, and because the LIRs that have existed since before 14 September 2012 (the day the main RIPE NCC IPv4 pool ran out) have had plenty of time to request their /22, this policy proposal also removes that "special" date from the policy text and treats all IPv4 allocations equally.Faits sourcés ↗
Version 2 changes the focus of the proposal, looking only at creating a waiting list based on an allocation size of /24 after the current policy no longer works. All other changes have been removed from this proposal and the proposal name has been changed accordingly.Faits sourcés ↗
La couverture de la source est incomplète.
Partielle
Première capture: 30 juin 1992
Dernière capture: 11 oct. 2026