قد تتطابق نسختان منشورتان من دون أن يتغير أي جهاز

الخلاصة

• تصف draft-ietf-netmod-iana-yang-guidance-03 انتقال وحدة YANG معيارية من نسخة قبل الإصدار وافقت عليها IESG، مرورًا بتغييرات يضبطها RFC Editor، واختيار المراجعة النهائية وYANG Semver، وإعادة التحقق، وصولًا إلى نشر شبه متزامن لدى RFC وIANA.
• يكون تطابق بايتات RFC وIANA إيصالًا قويًا لواقعة النشر، لكنه لا يثبت أن التحرير حافظ على المعنى، أو أن رفع رقم النسخة كان صحيحًا، أو أن عميلًا جلب هذه البايتات، أو أن جهازًا حمّلها، أو أن السلوك التشغيلي بقي متوافقًا.
• تسلك الوحدات التي ينشرها IETF والوحدات التي تديرها IANA والمشتقة من سجلات مرافقة مسارين مترابطين لكن مختلفين. لا يُعد نشر السجل ولا نجاح الأداة شهادة تشغيلية.

تخيّل خزانتين زجاجيتين تُفتحان في اللحظة نفسها تقريبًا. الأولى جزء من نشر RFC، والثانية هي نسخة سجل IANA لأسماء وحدات YANG. البايتات في الداخل متطابقة. هذا التناظر مقصود وذو قيمة، لأنه يعفي المشغل من تخمين الجهة التي تملك النسخة النهائية.

لكن الخزانتين المتطابقتين تقفان في نهاية عملية نشر، لا في نهاية عملية إدخال إلى الخدمة. تستطيعان إثبات اتفاق سطحين للنشر، ولا تستطيعان إخبارنا بما حدث أثناء حكم تحريري دلالي، أو في ذاكرة عميل مؤقتة، أو محمّل خادم، أو مخطط فعّال، أو مخزن بيانات، أو مسار حزم.

هذه الحدود هي الخبر الحقيقي في المراجعة 03 من Guidance for Managing YANG Modules in RFCs and IANA Registries. سجل Datatracker الحي الذي فُحص في 11 سبتمبر يصف Internet-Draft نشطة لمجموعة NETMOD في المراجعة 03، بالحالتين WG Document وI-D Exists، وبحالة مقصودة هي Informational. يحمل النص تاريخ 6 يوليو 2026 وتنتهي صلاحيته في 7 يناير 2027. يشير تاريخ «Last updated» في 27 أغسطس إلى تغييرات في shepherding AD وبيانات الحالة المقصودة؛ أما أحدث مراجعة للنص فما زالت مؤرخة في 6 يوليو. لم تصبح المسودة RFC، ولا يجوز وصف أي تسليم تقترحه كحدث إنتاجي مكتمل.

وسم ما قبل الإصدار يحفظ مجال التحرير

تبدأ السلسلة المقترحة عند نقطة مفيدة. فعند موافقة IESG، يُتوقع عادة أن تحمل الوحدات المعيارية معرّفات ما قبل الإصدار، مثل رقم رئيسي صفري أو release candidate يلحق به رقم المسودة. ليس ذلك إهمالًا؛ بل تصريح بأن المحتوى لم يكتسب بعد ثبات المراجعة المنشورة.

أثناء معالجة RFC Editor، يمكن توضيح الأوصاف من دون تغيير معناها، واستبدال مراجع المسودات بأرقام RFC النهائية، وتصحيح الأخطاء الطباعية، وتوحيد التنسيق. ترسم المراجعة 03 حدًا للصلاحية: تمضي التغييرات التحريرية كالمعتاد، أما التغييرات الجوهرية فتستلزم التنسيق مع المؤلفين. وإذا كان وصف ما قد يغيّر الدلالة أو كان تصنيف BC/NBC غير واضح، تحيل الوثيقة المسألة إلى مراجعة بشرية إضافية.

قبل النشر، يُحدد تاريخ المراجعة النهائي، ويُحذف مؤشر ما قبل الإصدار، وتُختار نسخة الإصدار وفق YANG Semver. وإذا كانت الوحدة منشورة سابقًا، فيلزم أيضًا مقارنتها بسابقتها وإضافة وسم rev:non-backwards-compatible عند الاقتضاء. وإذا غيّر التحرير اللاحق الوحدة مرة أخرى، وجبت إعادة النظر في قرار النسخة. لذلك يسجل المعرّف النهائي حكمًا على المرشح النهائي؛ ولا يثبت أن الحكم معصوم من الخطأ.

نطاق التحقق هو البايتات والتبعيات والأدوات

توصي المراجعة 03 بإعادة التحقق بعد التحرير والتنسيق، وعادة باستخدام pyang وyanglint. وتشدد أيضًا على مجموعة التبعيات الصحيحة. قد يلزم استخراج الوحدات المنشورة معًا وفحصها معًا؛ فنجاح الفحص مقابل دليل تبعيات ملائم لكنه مختلف يجيب عن سؤال آخر.

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

وعليه فإن «لا تحذيرات ولا أخطاء» إيصال دقيق: هذه النسخة من الأداة قبلت هذه البايتات مع هذه التبعيات وهذه الخيارات. لكنه ليس إيصالًا لحفظ الدلالة أو اكتمال التوافق أو صحة الإدخال إلى الخدمة.

تنتظر IANA البايتات النهائية ثم تنشر بجانب RFC

تطلب المسودة من IANA ألا تنشر الوحدة المعيارية قبل اكتمال عمل RFC Editor. وبعد حسم النص، يحمل RFC الوحدة، وتنشر IANA النسخة المقابلة في سجل YANG Module Names في الوقت نفسه تقريبًا. الغاية هي التطابق الدقيق وصحة المراجع النهائية.

هذا تزامن نشر، لا تنفيذ موزع. لإثباته، يحتفظ المدقق بالبايتات المستخرجة من RFC، وكائن IANA، وبصماتهما، وأوقات الجلب، وبيانات المراجعة والنسخة النهائية. وحتى التطابق الكامل لا يقول شيئًا عن مرآة لوحظت في وقت أسبق، أو عنوان URL بلا لاحقة في ذاكرة عميل، أو حل حزمة، أو مجموعة YANG Library التي أعلنها الخادم، أو تحميل العملية، أو اختيار features وdeviations، أو ترحيل بيانات المثيل، أو السلوك التشغيلي.

تملك تغطية BTW المجاورة لأسماء ملفات YANG أدلة الأسماء البديلة واختيار المحمّل؛ وتملك مقارنة المخططات تصنيف فروق ED/BC/NBC؛ ويملك تحديد نسخ الوحدات الفروع والأنساب؛ وتملك الحزم التركيب العودي. أما مساهمة هذه المسودة المنفصلة فهي التسليم المنضبط الذي يجمّد مرشح نشر واحدًا ويجعل سطحي النشر متطابقين.

الوحدات المشتقة من السجلات تتبع ساعة أخرى

تنتقل المراجعة 03 بعد ذلك إلى فرع مختلف. فالوحدة التي تديرها IANA ليست مجرد نسخة ثانية من وحدة IETF. إنها إسقاط مقروء آليًا لسجل مرافق، غالبًا مبني على تعدادات أو identities. تدخل القيم الجديدة أولًا إلى السجل المرافق المرجعي؛ ثم تحدد IANA فرق السجل، وتطبق تغيير الوحدة المقابل، وتضبط مراجعة ونسخة جديدتين، وتفحص التصنيف، وتتحقق، وتنشر مواد يمكن عنونتها بالنسخة والتاريخ.

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

تستمر سلسلة الأدلة بعد النشر

يفصل الإغلاق القابل للدفاع بين تسعة سجلات على الأقل: مرشح المسودة الموافق عليه؛ كل تغيير واستشارة لدى RFC Editor؛ حكم المراجعة وSemver النهائي؛ مدخلات التحقق الدقيقة وإصدارات الأدوات؛ بايتات RFC المستخرجة؛ بايتات IANA المنشورة ووقت جلبها؛ أصل جلب العميل وذاكرته المؤقتة؛ تحميل الجهاز والمخطط الفعّال المعلن؛ والسلوك الملحوظ لمخزن البيانات والبروتوكول والخدمة.

يوفر مبدأ Running-Code Primacy لهينغ لو انضباط التفسير، لا ادعاءً عن نية IETF: يمكن لأداة تنسيق أن تصف هدف توافق من دون أن تجعل التبني واقعًا. ويعزز Minimum Initial Specification الجزء النافع في المسودة، لأن عقد النشر ضيق وحتمي حيثما أمكن وقابل للفحص محليًا. ويتطلب Reality, Not Advocacy وReality Layers أن يتوقف السرد عند آخر طبقة مرصودة.

لذلك ليست نسختان منشورتان متطابقتان أمرًا هينًا. إنهما تزيلان غموضًا لا ينبغي أن يصل إلى المشغلين. وتأتي قوتهما من رفض توثيق ما وراء ذلك.

المصادر

1. نص المراجعة 03
2. سجل Datatracker الحي
3. سجل التغييرات في Datatracker
4. RFC 9907
5. RFC 9890
6. RFC 7950
7. YANG Module Versioning، المراجعة 17
8. YANG Semantic Versioning، المراجعة 26
9. YANG Schema Comparison، المراجعة 09
10. YANG Module Filename، المراجعة 14
11. IANA YANG Parameters
12. Heng Lu — Running-Code Primacy
13. Heng Lu — Minimum Initial Specification
14. Heng Lu — Reality, Not Advocacy
15. Heng Lu — Reality Layers