ما الذي تغيّر
لا يمكن إثبات أي تغير في نص السياسة أو مسارها أو وضعها الرسمي، لأن التسلسل الزمني الموثق فارغ ولا توجد خطوط زمنية للمواقف أو وقائع قرار ضمن السجل المقدم.
RIPE NCC · مراقبة سجلات الإنترنت الإقليمية
ابدأ من هنا للاطلاع على سجل كل مقترح على حدة: ما الذي تغيّر، ولماذا كان مهمًا، ومن دافع عن أي موقف، وكيف تطورت المواقف، وما الذي تقرر، وأين لا تزال هناك ثغرات في الأدلة.
حقائق موثقة
من الذي شكّل النقاش فعلياً؟
تحليل BTW
لا يمكن إثبات أي تغير في نص السياسة أو مسارها أو وضعها الرسمي، لأن التسلسل الزمني الموثق فارغ ولا توجد خطوط زمنية للمواقف أو وقائع قرار ضمن السجل المقدم.
لا يمكن تحديد موضوع النقاش الجوهري أو المصالح والحوافز المتعارضة، لأن السجل لا يحتوي على رسائل أو مشاركين أو مواقف أو حجج موثقة. ومن ثم لا يدعم نسبة أهداف أو تحالفات أو سيطرة على جدول الأعمال إلى أي طرف.
لا توجد مناقشة مرصودة في البيانات المقدمة: عدد الرسائل والمشاركين والجهات الرسمية والأيام النشطة يساوي صفرًا. كما لا يوجد سجل قرار، ولذلك لا يمكن تحديد ما إذا كان المقترح قد أُقر أو رُفض أو سُحب أو بقي دون حسم، ولا يجوز استنتاج نتيجة قرار من غياب النشاط المرصود.
قيم حصص الرسائل لأعلى مشارك وأعلى خمسة وأعلى عشرة، وكذلك مؤشر 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.حقائق موثقة ↗
تغطية المصدر غير مكتملة.
جزئية
أقدم مادة محفوظة: 30/06/1992
أحدث مادة محفوظة: 11/10/2026