اختار اجتماع VELOCE مؤشراً لدى IANA، لكن مسودة المجموعة ما زالت بلا إجراءات لها

الخلاصة

• اعتمدت OPSAWG عمل VELOCE ونشرت المراجعة 00 بوصفها وثيقة مجموعة عمل في 25 أغسطس 2026. وهذه ليست RFC ولا BCP ولا قاعدة IETF نهائية.
• يقول ملخص الاجتماع المنسوب إن نموذج مؤشر IANA قد تأكد، بينما تنص المراجعة 00 صراحة على عدم وجود إجراء IANA. وكانت pull request 49، التي تقترح حالات وبصمات ومسارات موافقة، مفتوحة وغير مدمجة عند حد البحث.
• لا تساوي نتيجة اجتماع مشروع قرار إجماع لمجموعة العمل تم تأكيده على قائمة البريد. ولا يساوي دمج في GitHub موافقة المجموعة أو Area Director أو IESG. ويمكن لسطر IANA أن يوثق نسخة معتمدة من دون أن يقرر معناها المعياري.
• تتجنب المسودة بالفعل إحالة RFC إلى رأس فرع متغير، وتطلب إصداراً ذا وسم محدد. ويبقى المطلوب وصل اعتماد النسخة اللاحقة، وحصول IANA عليها والتحقق منها، والإصدار الذي يحق للمنفذ أن يختبر المطابقة عليه.

أربعة أفعال متجاورة لا تصير فعلاً واحداً

سجلت نتيجة الاعتماد أن رئاسة OPSAWG وجدت دعماً كافياً وطلبت إعادة تقديم النص الفردي باسم draft-ietf-opsawg-veloce-yang-00 من دون تغيير آخر. وتعرض سجلات Datatracker المراجعة 00 وثيقةً للمجموعة منذ 25 أغسطس. هذا ينقل الوثيقة إلى مسؤولية المجموعة؛ ولا يمنح مسبقاً شرعية كل تفصيل لاحق في التسجيل أو التحديث.

يقترح النص ألا تُدرج وحدة YANG في RFC. بل يشير RFC إلى نسخة محددة وموسومة في المستودع. يمكن أن يتغير الفرع الرئيس بعد النشر، أما commit أو tag محدد فيتيح لقارئ لاحق استرجاع البايتات نفسها والتحقق منها. ويتصور النص أيضاً تحديث وحدة معتمدة في مستودع IETF، مع تغيير الإحالة في RFC فقط. لهذه الفكرة منفعة عملية: التصحيح المحدود الذي خضع لمراجعة لا يلزم أن يفتح استبدال RFC كاملاً كل مرة.

لكن RFC كان يجمع، بصمت، أشياء يجب تفكيكها الآن: النص المعياري، والنسخة المنشورة، وفعل الموافقة، والمرجع المستقر. عرض المؤلفون الأسئلة علناً قبل IETF 126. تسأل مناقشة المؤشر إن كان RFC ينبغي أن يشير إلى Git tag أو إلى قيد IANA أو إلى هدف آخر؛ وما الذي يعنيه مؤشر «الأحدث»؛ وأي نسخة ينبغي أن يستخدمها المنفذ؛ وكيف تبقى المطابقة قابلة للاختبار بعد التحديث. وتحتفظ محاضر OPSAWG في IETF 126 بآراء متباينة عن GitHub وبيئة تسيطر عليها IETF وIANA والأرشفة والاسترداد. انتهى الوقت المخصص واستمر النقاش على القائمة. ذلك دليل على مسألة تصميم مفتوحة، لا اتهام لأحد.

ويضيف ملخص 25 أغسطس أن مستودع GitHub سيبقى للتجربة، وأن المساهمين يستطيعون فتح issues أو pull requests، وأن آراء الاجتماعات نصف الشهرية ستلخص على قائمة البريد، وأن الاعتراضات تقود إلى نقاش إضافي قبل الدمج. ويقول أيضاً إن نموذج الإحالة عبر IANA تأكد. لكن نوع الدليل لا يجوز تضخيمه. إنه حساب منسوب لاجتماع مشروع، لا دعوة إجماع رسمية للمجموعة ولا قرار IESG. ينص RFC 8874 على أن العمل في GitHub لا يملك صفة خاصة، وأن قرارات إجماع المجموعة ينبغي أن تؤكد على قائمة البريد. يمكن للاجتماع أن يدفع الاقتراح إلى الأمام، ولا يمكنه أن يحل محل التأكيد.

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

PR49 رسم لدفتر سجل، لا دفتر سجل قائم

كانت PR49 مفتوحة وغير مدمجة عند حد البحث. تقترح سجلاً لإحالات ملفات ووحدات YANG، بحالات دائمة ومقترحة، وعنوان URL دقيق، وSHA-256، وجهات اتصال مسيطرة، ومسارات موافقة عبر IESG أو جهات محددة أخرى. هذه عناصر مفيدة للفصل: البصمة تثبت البايتات، والحالة تفصل المرشح عن القيد الساري، والاتصال يحدد الحضانة، ومسار الموافقة يسمي من يحكم في المضمون.

لكن الأعمدة المقترحة ليست بعد سياسة تسجيل عامة. يعمل سجل أسماء وحدات YANG الحالي لدى IANA بسياسة RFC Required، ويعرض الاسم والملف وnamespace وprefix والمرجع والملاحظات. ولا يعرض اليوم حقول VELOCE المقترحة للبصمة أو حالة الموافقة أو جهة التحكم أو إيصال القرار. لذلك لا يسمح السجل المجمد بالقول إن IANA أنشأت السجل الجديد، أو قبلت قاعدته، أو جلبت إصداراً من VELOCE.

الفصل هنا يحمي كل مؤسسة. يقترح المؤلف التغيير؛ ويعالجه المراجعون والقائمون على المستودع؛ وتشكل مجموعة العمل الإجماع؛ وقد يوافق Area Director أو IESG وفق النص؛ وتنفذ IANA تسجيلاً محدداً؛ ويحفظ القيد هوية إصدار. tag وmerge والإجماع والموافقة والقيد أفعال متصلة أحياناً، لكنها ليست الدليل نفسه. فإذا صارت IANA هي من يحكم على نضج المضمون خرجت عن دور المسجل. وإذا صار merge دليلاً على الإجماع أخذت صلاحية المستودع مكان المداولة. وإذا صارت tag دليلاً على التبني خلطنا البايتات القابلة للتكرار بقرار المشغل.

والقراءة الحذرة لا تنكر نقاط القوة. تمنع المراجعة 00 الفرع العائم وتحافظ على إجراءات الإجماع. وتحاول PR49 تقييد دور IANA بالبصمات ومسارات الموافقة، لا منحها سلطة مطلقة. وقد يكون من الطبيعي أن تسبق مراجعة مبكرة للمجموعة حسمَ نقاشٍ ما زال مفتوحاً.

إيصال صغير من القرار إلى المؤشر

لا يحتاج VELOCE إلى سلطة معيارية ثانية ولا إلى RFC كامل لكل تصحيح محدود. لكل تغيير تالٍ، يمكن لإيصال علني متصل أن يجمع:

1. الأثر المعياري المدعى والمجموعة المسؤولة؛
2. دعوة الإجماع على القائمة وتواريخها واعتراضاتها الجوهرية وتصرف الرئاسة؛
3. النص الدقيق الذي يطلب التسجيل والجهة التي تعتمد؛
4. عنوان المستودع وcommit الثابت وtag وSHA-256؛
5. المؤلفين والمراجعين ومن دمج التغيير وصاحب سلطة الموافقة كأدوار منفصلة؛
6. طالب IANA ووقت الطلب والرابط الذي جُلب والبايتات ونتيجة التحقق؛
7. القيد السابق والقيد الجديد ووقت النفاذ وعلاقة الاستبدال؛
8. إصدار النشر، وآخر إصدار معتمد، وإصدار اختبار المطابقة؛
9. التوافق والاختبارات والمرايا والنسخ الاحتياطية والاسترداد والسحب والرجوع؛ و
10. دليل التطبيق أو التبني التشغيلي، منفصلاً عن التسجيل.

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

وينطبق الفصل على المطابقة. يبقى RFC 9907 هو BCP المنشور: فعبارات YANG المعيارية تعامل كنثر RFC معياري، وتُسجل الوحدات الجديدة أو المحدثة في IETF XML وYANG Module Names. قد يقترح VELOCE ترتيب صيانة مختلفاً، لكنه لم يستبدل هذه القاعدة عند حد البحث. وقد تتطابق نسخة RFC ونسخة IANA الحالية وآخر نسخة معتمدة والنسخة المختبرة؛ ولا ينبغي افتراض ذلك حين لا تتطابق.

Sources

1. OPSAWG charter
2. VELOCE Datatracker record
3. IETF 126 OPSAWG minutes
4. Pull request 49
5. Heng Lu Note 63
6. IANA YANG parameters
7. OPSAWG VELOCE adoption result
8. VELOCE pointer discussion
9. 25 August VELOCE call summary
10. draft-ietf-opsawg-veloce-yang-00
11. RFC 8126
12. RFC 8874
13. RFC 8875
14. RFC 9907