الخلاصة

  • يقترح draft-ietf-opsawg-veloce-yang-00 أن يشير المنشور إلى وسم أو commit محدد بدلاً من HEAD المتغير. هذا دليل قوي على هوية المحتوى، لكنه لا يحوّل الدمج أو إغلاق issue أو نجاح CI إلى توافق تلقائي داخل مجموعة العمل.
  • بعد النشر تبقى حلقات أخرى: حفظ قرار الحوكمة، وحيازة الإصدار، ومجموعة الوحدات التي يعلنها الخادم عبر YANG Library، ونجاح العمليات التمثيلية، والأثر المرصود على الخدمة.

يمكن أن يبقى الكود كاملاً وتضيع السلطة التي أجازت ذلك الكود.

هذه ليست مفارقة في Git. فالنظام صُمم لحفظ تاريخ الكائنات والتغييرات. أما سبب قبول تغيير بعينه، ومن اعتبره توافقاً، وأي إصدار وصل إلى جهاز فعلي، فهي حقائق تقع في طبقات أخرى.

يتناول VELOCE هذه الفجوة من خلال اقتراح فصل وحدة YANG عن النص التفسيري المصاحب لها. تبقى في الوثيقة اعتبارات الأمن والتشغيل ومراجع IANA وشرح النموذج، بينما تُطوّر الوحدة في مستودع لإدارة الشيفرة، مع فروق صغيرة وissues وpull requests والتحقق الآلي وبيئة حاوية قابلة لإعادة الإنتاج.

الفكرة عملية لأن YANG ليس نثراً فقط. إنه مصدر تقرؤه أدوات ومخدمات وعملاء، وله imports وrevisions وfeatures وdeviations وقد يصاحبه ملف SID. مراجعة تغيير صغير كفرق شيفرة قد تكون أدق من إعادة فتح وثيقة كبيرة كاملة.

المادة المجمدة هي Internet-Draft نشط لمجموعة OPSAWG بتاريخ 25 أغسطس 2026. يذكر رأس النص أن الحالة المقصودة Experimental، بينما لا يعرض ملخص Datatracker حالة RFC مقصودة. لا يسجل التاريخ سوى النسخة 00. ليست الوثيقة RFC ولا تجربة مكتملة ولا دليلاً على انتشار. المهل المقترحة—سنتان لوحدة جديدة وسنة لنسخة -bis تدريجية—معايير اختبار مستقبلية.

أوضح قواعد الاقتراح هي ألا تُدرج وحدة YANG في الوثيقة. يجب أن يشير الرابط إلى وسم محدد أو hash لالتزام، لا إلى رأس فرع. عندئذ تبقى الوحدة المقصودة وقت النشر قابلة للاسترجاع والتحقق.

الوسم أفضل كثيراً من عنوان متحرك. فهو يسمح للمراجع وYANG Doctor والمنفذ والمدقق بالنظر إلى الكائن نفسه. لكنه يجيب عن سؤال واحد: أي محتوى؟

لا يجيب عن سؤال: من منحه السلطة؟

ينص RFC 8874 على أن العمل المنجز في GitHub لا يتمتع بوضع خاص. يمكن لمجموعة العمل أن تقبله أو ترفضه أو تعدله. كما لا يلزم أن تعكس نسخة المستودع توافق المجموعة على نحو كامل في كل لحظة، لأن المحررين يحتاجون مرونة لإدارة الوثيقة.

واجهة المستودع تخفي هذه المسافة. تظهر pull request على أنها Merged، وissue على أنها Closed، وcheck على أنه Passed. وقد يحمل label اسم has-consensus. هذه حالات حقيقية، لكنها لا تستمد الشرعية من شكلها الثنائي أو من الاسم المكتوب عليها.

يطلب RFC 8874 تأكيد قرارات التوافق في القائمة البريدية، ويضع التقدير النهائي لدى الرؤساء. ويشرح RFC 2418 أن rough consensus ليس تصويت أغلبية، وأن قرارات الاجتماعات تعود إلى القائمة للمراجعة. على الرئيس أن ينظر في ساحات متعددة وفي انحياز المشاركة داخل كل ساحة.

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

الإيصال المتين يربط أربعة أشياء: السؤال التقني، والحل المقبول، وتحديد الرئيس لنطاق التوافق، والـcommit الذي نفذ ذلك الحل. إذا حُفظ القرار والكود كل على حدة، تبقى مطابقتهما افتراضاً.

أما CI فيصدر دليلاً مختلفاً. يذكر RFC 8874 بناء الوثائق والتحقق من اللغات الشكلية وتشغيل الاختبارات. ويوصي VELOCE بتحقق YANG وبيئة حاوية تمكّن المساهمين من إعادة الفحص محلياً.

اللون الأخضر يعني نجاح اختبارات مسماة على مدخلات مسماة. يتحدد نطاقه بالـcommit وإصدار المدقق والاعتمادات والfeatures والإعداد وصورة الحاوية ومجموعة الاختبار. لا ينجح اختبار لم يُكتب، ولا يثبت أن منتجين سينفذان كل قيد بالطريقة نفسها.

المطلوب ليس تقليص الأتمتة بل حفظ مقامها. يجب أن يرافق الحكم سجل بالأداة والإصدار والاعتمادات والخيارات والاستثناءات حتى يمكن إعادة إنتاجه وفهم حدوده.

يضيف النشر سلطة معيارية، لكنه لا يشغّل الوحدة. يمكن أن يربط RFC بين النص والكائن الدقيق الذي راجعه الخبراء، وهي فائدة مهمة. لكنه لا يبني حزمة المورد ولا يفعّل الوحدة في datastore.

بين الوسم والجهاز توجد حيازة المستودع، وبناء الإصدار، والتوقيع، واختيار الاعتمادات، ودمج المورد، وصورة النظام، والتوزيع والتفعيل المحلي. أي انتقال غير موثق قد يكسر السلسلة مع بقاء الـcommit الأصلي سليماً.

ولا تكفي نسخ Git لحفظ سياق القرار. يحذر RFC 8874 من أن مناقشات issues وpull requests والمراجعات وwiki أكثر عرضة للضياع من كائنات المستودع. كما تبقى أعطال الخدمة الخارجية واختراق حسابات الامتياز مخاطر. ويكمل RFC 8875 قواعد الإدارة والنسخ الاحتياطي.

الاحتفاظ بالنتيجة وفقدان سبب قبولها يحفظ الشكل التقني ويضعف قابلية إثبات السلطة.

أول إيصال وقت تشغيل يأتي من الخادم. يتيح RFC 8525 لـYANG Library أن تعلن module-sets الخاصة بالـdatastores، بما فيها revisions وfeatures وdeviations. يستطيع المشغل مقارنة هذا الإعلان مع الوسم المنشور.

حتى التطابق ليس خاتمة. YANG Library تصريح من الخادم عن المخطط. ما زالت هناك حاجة إلى عمليات NETCONF أو RESTCONF تمثيلية، وقراءة لاحقة للحالة، وملاحظة مستقلة للخدمة. هوية المخطط وقبول العملية وأثر الشبكة ثلاث دعاوى منفصلة.

تضع عدسة running-code الأدلة في ترتيبها الصحيح. الوسم يخص المستودع، والتوافق يخص القرار، وRFC يخص النشر، والمخطط المحمّل والسلوك يخصان النظام العامل. لا تلغي طبقة أخرى، ولا تتحدث نيابة عنها.

ويقدم مبدأ الحد الأدنى للمواصفات الأولية حلاً بنّاءً: توحيد الروابط اللازمة فقط—الكائن الدقيق، والتحقق القابل للإعادة، والقرار القابل للتتبع، ومرجع النشر غير المتغير—مع إبقاء الأدوات وسلاسل التسليم قرارات محلية. بعد ذلك تختبر التطبيقات المستقلة والتبني الطوعي القيمة الفعلية.

هناك أيضاً خطر في تمثيل المشاركة. من يتابع كل issue عينة منتقاة ذاتياً، وخبراء آخرون يتابعون القائمة البريدية فقط. النشاط المرئي ليس تفويضاً. إعادة ربط المستودع بالقائمة والرؤساء تحمي اتساع العملية.

ينجح VELOCE إذا سرّع الصيانة من دون ضغط خمسة إيصالات في وسم واحد. عندما يقال إن الوحدة «جاهزة»، يجب السؤال: هل اكتمل المحتوى، أم التوافق، أم النشر، أم المنتج، أم النتيجة التشغيلية؟

المصادر