发生了什么变化
没有提供任何政策时间线或版本差异,因而无法确定 ripencc/2019-02 的文本、范围、机制或状态发生了什么变化。当前唯一可确认的是:在来源修订 de28b2cc24ecfeb6963ed6c9b69fb8c9d56964e526d9b1d9fca4f7e6164656bf 对应、计算于 2026-08-27T16:14:23.200273+00:00 的事实快照中,没有记录可观察的政策活动。
RIPE NCC · RIR 观察
从这里开始,逐项查看提案记录:发生了哪些变化、为何重要、各方提出了什么主张、立场如何演变、最终作出了什么决定,以及证据仍存在哪些缺口。
来源事实
究竟是谁影响了这场辩论?
BTW 分析
没有提供任何政策时间线或版本差异,因而无法确定 ripencc/2019-02 的文本、范围、机制或状态发生了什么变化。当前唯一可确认的是:在来源修订 de28b2cc24ecfeb6963ed6c9b69fb8c9d56964e526d9b1d9fca4f7e6164656bf 对应、计算于 2026-08-27T16:14:23.200273+00:00 的事实快照中,没有记录可观察的政策活动。
由于没有讨论消息、立场时间线、提案文本或未解决及少数意见,无法确定争论的实质议题、利益冲突、政策目标或参与者动机;任何更具体的主题归纳都会超出已验证事实。
讨论消息数、讨论参与者数、正式行为方数和活跃天数均为零,且政策时间线为空。因此既无法重建讨论过程,也无法确认是否存在通过、撤回、搁置、替代、失效或其他正式决定;零记录不等于没有讨论或没有决定。
消息总数和参与者总数均为零;top-1、top-5、top-10 消息份额、HHI、有效参与者数及核心参与者数量也均为零。这些指标反映当前没有可计算的消息分布,不能解释为参与分散、竞争充分、权力均等或讨论由少数人集中控制。
现有快照未记录政策时间线、讨论消息、参与者、正式行为方或决定节点,因此无法识别议程设置、评审、共识判断、正式批准等环节中的实际把关点,也不能把零记录解释为不存在制度性把关。
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.来源事实 ↗
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.来源事实 ↗
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).来源事实 ↗
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.来源事实 ↗
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.来源事实 ↗
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.来源事实 ↗
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.来源事实 ↗
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.来源事实 ↗
来源覆盖尚不完整。
部分
最早收录: 1992年6月30日
最近收录: 2026年10月12日