اعتمدت INTAREA مسودة لتنظيف السجلات ولم تطبقها IANA بعد

الخلاصة

• سجل Datatracker في 11 سبتمبر 2026 الموافقة على النسخة draft-ietf-intarea-legacy-registries-00 بوصفها نسخة مجموعة العمل. ما زالت الوثيقة Internet-Draft وليست RFC.
• تطلب المسودة إغلاق سجل واحد، ووضع إجراء IESG Approval لسجل آخر، واعتماد First Come First Served لسجلين، وحذف سجل TTL أو استبدال ملاحظته.
• ما زالت صفحات IANA الخمس تعرض حالتها السابقة. ويحتاج كل فعل إلى إيصال مستقل يربط مرحلة الوثيقة بقرار التنفيذ وبمصير البيانات القديمة.

انتقلت المسؤولية ولم تنتقل سلطة التنفيذ

تعرض صفحة Datatracker الحالية وثيقة “Updates to Legacy IANA Registries” ضمن أعمال INTAREA. ويبين سجل النسخة التابعة للمجموعة أن النسخة -00 أجيزت في 11 سبتمبر وأنها حلت محل سلسلة المسودة الفردية.

للاسم الجديد معنى مهم. فقد قبلت مجموعة العمل أن تطور النص جماعياً وأن تتولى معالجة الاعتراضات اللاحقة. لكنه لا يعني أن IETF وافقت على Proposed Standard، ولا يحول صياغة الطلبات المستقبلية في قسم IANA Considerations إلى سجل لتنفيذ مكتمل.

يضيف تاريخ المسودة الفردية قيداً ضرورياً. ففي 27 أغسطس سجل الرؤساء وجود توافق على تبني الوثيقة، وأشاروا أيضاً إلى اعتراض رأوا أنه سُمع ونوقش. ووصفوا موضوع النص بأنه صيانة لإجراءات السجلات، لا موقفاً من مستقبل IPv4. يمكن للمجموعة أن تتبنى مسألة تستحق العمل من دون أن تدعي انتهاء النقاش في كل عبارة.

ولم يحمل الانتقال تعديلاً جوهرياً مستتراً. فالطلبات نفسها موجودة في النسخة الفردية 03 وفي نسخة المجموعة 00. اقتصرت الفروق الظاهرة على تصحيح نحوي في الاعتبارات الأمنية وإضافة اسم إلى الشكر. الدليل الجديد يتعلق بمن يدير النص، لا بما نفذته IANA.

كلمة تنظيف تخفي أربعة أفعال

تجمع المسودة مشكلات قديمة في وثيقة قصيرة، لكنها لا تضع السجلات الخمسة في حالة واحدة.

بالنسبة إلى NetWare/IP Option Type 63 Sub-Option Codes، تطلب إغلاق السجل لأن NetWare لم يعد يتوسع. الإغلاق يوقف التسجيلات الجديدة ولا يبطل القيم القديمة. وتوضح RFC 8126 أن معلومات السجل المغلق تبقى صحيحة، وأن السجلات القائمة تظل قابلة للتحديث ومحفوظة للأغراض التاريخية.

أما IP Option Numbers فلا تقترح المسودة إغلاقه، بل تحديد إجراء IESG Approval. يسمح هذا الإجراء لـ IESG بالموافقة على تعيين جديد حالة بحالة، من دون اشتراط RFC دائماً، مع إمكان طلب وثائق أو استشارة المجتمع. وتصفه RFC 8126 بأنه مسار استثنائي نادر الاستخدام، لا الإجراء المعتاد. لذلك لا يصح تحويله إلى ادعاء بحظر أرقام خيارات IPv4.

وتتجه Machine Names وTerminal Type Names في الاتجاه المقابل. سيحصل كلاهما على First Come First Served، أي حد أدنى من الوثائق ومن دون مراجعة فنية. تعترف المسودة بإمكان وصول طلبات غير معقولة وتعتمد على الترشيح المعتاد لدى IANA. إنشاء باب واضح لسجلين خامدين منذ عقود ليس إغلاقاً لهما.

أما IP Time to Live Parameter فتطلب المسودة حذفه لأن نظام التشغيل أو التطبيق يستطيع اختيار TTL بحرية. وإذا تعذر الحذف الكامل، تقترح نصاً بديلاً للملاحظة. حذف الصفحة والإبقاء عليها مع ملاحظة جديدة وإغلاق باب التسجيل نتائج أرشيفية مختلفة تماماً.

صفحات IANA تحفظ صورة ما قبل التغيير

لا تزال صفحة معلمات DHCP وBOOTP تعرض قيم NetWare وتكتب Not defined في خانة الإجراء. ولا تظهر عليها علامة إغلاق.

وفي صفحة معلمات IPv4، بقي إجراء IP Option Numbers هو Not defined. كما بقي سجل IP Time to Live Parameter وملاحظته التي توصي بالقيمة الافتراضية 64. والقيم التجريبية ما زالت موثقة، من دون ظهور IESG Approval كسياسة نافذة.

ويظل سجل Machine Names عند Not defined. أما Terminal Type Names فيحتفظ بعبارة Not defined? بعلامة الاستفهام. لم يظهر First Come First Served في أي منهما.

لا يثبت هذا تأخراً من IANA. تذكر RFC 8126 أن IANA تنفذ الإجراءات عادة عندما تعتمد الوثيقة للنشر، وهذه المسودة ما زالت قيد التطوير. توضح قائمة وثائق INTAREA حالة النص، بينما توضح صفحات IANA القاعدة النافذة. لا يغني أحد السطحين عن الآخر.

حملت المجموعة الخلاف معها

توثق محاضر INTAREA في IETF 126 قلقاً من أن تضييق إتاحة أرقام خيارات IPv4 قد يعرقل استخدامات مشروعة داخل نطاقات محدودة. كما سجلت دعوة إلى حفظ المعلومات عندما تصبح التقنيات قديمة. وأشار المؤلف إلى القيم التجريبية وإلى بقاء الإدخالات.

وفي نقاش التبني ظهرت اعتراضات على كيفية وصف موثوقية خيارات IPv4 وعلى احتمال الاستشهاد بالمبررات لاحقاً بصورة أوسع من موضوعها. وظهرت رسائل تأييد أيضاً. قرار الرؤساء يضع هذا النقاش في عهدة المجموعة ولا يمحوه من السجل.

الصياغة الدقيقة إذن هي أن INTAREA تبنت الوثيقة للعمل عليها. لم تعتمد بعد كل طلب بصيغته النهائية، ولم تصدر عن IANA شهادة تنفيذ.

إيصال لكل عملية لا لعنوان المشروع كله

يمكن نشر إيصال إجراء للسجل لكل طلب عندما يتقدم العمل. هذا اقتراح تحريري، وليس مطلباً قائماً لدى IETF أو IANA.

يسجل الإيصال الاسم والرابط الدقيقين للسجل، ونسخة مؤرخة من حالته السابقة، ورقم المسودة وبصمتها، والفعل المطلوب، ومراحل مجموعة العمل وIESG، وتأكيد IANA، والمرجع النافذ، والحالة اللاحقة، وطريقة حفظ القيم القائمة.

يحتاج Machine Names وTerminal Type Names إلى إيصالين حتى لو حصلا على السياسة نفسها. ويجب وصف NetWare بأنه مغلق مع حفظ القيم، لا محذوف. وبالنسبة إلى TTL، ينبغي القول هل أزيلت الصفحة أم استخدمت الملاحظة البديلة. وإذا تغيرت سياسة IP Option Numbers في نسخة لاحقة، يبقى الطلب السابق ظاهراً في التسلسل.

تكفي هذه البيانات القليلة لمنع تبديل الأدلة. الاسم الجديد يثبت أن INTAREA تولت تطوير الوثيقة. RFC مستقبلية ستثبت النص المعتمد. وتغيير صفحات IANA وحده سيثبت التنفيذ. لا ينبغي وضع الحالات الثلاث تحت تاريخ واحد.

المصادر

1. IETF Datatracker — وثيقة مجموعة العمل
2. تاريخ وثيقة المجموعة
3. نسخة المجموعة 00
4. تاريخ المسودة الفردية المستبدلة
5. النسخة الفردية 03
6. محاضر INTAREA في IETF 126
7. نقاش تبني الوثيقة
8. IANA — معلمات DHCP وBOOTP
9. IANA — معلمات IPv4
10. IANA — Machine Names
11. IANA — Terminal Type Names
12. RFC 8126 — إرشادات تسجيلات IANA
13. قائمة وثائق INTAREA