الخلاصة

  • يجعل draft-feng-netmod-naim-01 صيغة Canonical JSON المصدر الموثوق لمحتوى NAIM، بينما تكون صفحة Markdown عرضاً مشتقاً للمراجعة، ويكون LLM Context View سياقاً مختصراً يحذف حقولاً عمداً.
  • يثبت تحقق المخطط، وسلامة التحويل ذهاباً وإياباً، ونجاح إعادة المحاولة، وقبول مدقق YANG اختبارات محددة فقط. ولا يثبت أي منها منفرداً اكتمال المتطلبات أو تبني NETMOD أو تنفيذ الخادم أو تفويض المستخدم أو تحقق النتيجة.

لنفترض أن الطلب يقول: «استخدم المسار الاحتياطي عند فشل المسار الأساسي، إلا لحركة المرور الخاضعة للتنظيم». يسأل المساعد عن المفتاح وقابلية الكتابة، ثم ينتج وثيقة سليمة. لكن إن لم يسأل من يقرر وقوع الفشل، وكيف تُعرّف الحركة المنظمة، وهل «استخدم» تعني الضبط أم التفويض أم التنفيذ، فلن تستعيد خوارزمية التحويل تلك الحقائق المفقودة.

تقترح المراجعة 01 من NAIM تمثيلاً دلالياً وسيطاً بين المتطلبات الطبيعية وYANG. وتنطلق من فجوة واضحة: التحويل المباشر يدفع الأداة إلى التخمين في الفصل بين الإعداد والحالة، ومفاتيح القوائم، وعبارات القيود، والشروط التشغيلية، والعلاقات بين الوحدات.

يجب ألا يتجاوز الوصف وضع الوثيقة. يسجل Datatracker مسودة فردية نشطة كتبها Chong Feng، حُدثت في 18 يوليو 2026، بلا stream وبلا intended RFC status مسجل، وحالتها I-D Exists. وتكتب ترويسة المسودة Intended status: Standards Track؛ وهذا هدف يعلنه المؤلف، لا تبنياً من مجموعة NETMOD ولا اعتماداً من IETF ولا RFC. أما السجل التاريخي فيثبت تواريخ النسخ فقط.

مصدر واحد للسلطة وعرضان بوظيفتين مختلفتين

تجعل المسودة Canonical JSON المصدر المعياري الوحيد. وتُلزم الأدوات المتوافقة بمنحه الأولوية. أما Markdown View فيُشتق بصورة حتمية للمراجعة البشرية والتحكم في النسخ. وإذا قبلت أداة Markdown كمدخل تعديل، فلا يجوز أن تسقط بصمت حقولاً موجودة في JSON وحده، ويجب أن يبقى معنى الحقول المعروضة مكافئاً، وأن يُحل التعارض صراحة.

لذلك لا تكفي عبارة «نجح round trip». ينبغي حفظ البايتات الأصلية والهاش ونسخة المخطط وهوية المحول وبصمات المخرجات وقائمة الحقول غير المعروضة وقرار كل تعارض. فالاختبار يثبت أمان سطح التحويل الذي اختُبر، لا صحة الطلب الذي سبقه.

أما LLM Context View فيحافظ على الأسماء والأنواع الدلالية والإلزام والقيود وقابلية الكتابة وشروط الظهور والعمليات والشروط السابقة والآثار الجانبية. لكنه يحذف تفاصيل بناء طلبات NETCONF/RESTCONF والبيانات الوصفية الداخلية وJSON Schema الخام وتصريحات deviation وتعريفات extension. وهو غير معياري ولا يجوز استخدامه لإعادة بناء Canonical JSON.

هذا الحذف مفيد لتقليل السياق، لكنه ليس بريئاً في كل مهمة. قد يغير deviation في الخادم أو augment خارجي المخطط الفعال. ويمكن للنموذج أن يكون أميناً تماماً للسياق الذي رآه وأن يكون غير مناسب للبيئة الحقيقية. المطلوب هو سجل يربط كل حذف بالمهمة ويشرح أين تُستعاد الصورة الكاملة.

فصل Specification عن Skill وعن Tool

تحدد طبقة Specification البنية والمخطط وقواعد توليد العروض. وتضم طبقة Skill عمليات الذكاء الاصطناعي: النمذجة الحوارية والتلخيص وتوليد YANG والهندسة العكسية. أما Tool فهي برمجيات حتمية للتحقق والتحويل والاستخراج والتوليد من مادة مؤكدة. يسمح ذلك بثبات الصيغة مع استبدال النموذج، ويمنع المدقق البنيوي من ادعاء فهم مقصد المؤسسة.

في Validation-Reflection-Retry تُصدر الأداة خطأ منظماً يتضمن المسار والشرط المتوقع، ثم يمكن حقنه في سياق النموذج وإعادة المحاولة. يجب أن يوجد حد أقصى، وبعده تتوقف الآلية وتعرض أسئلة محددة وتحفظ سجل التصحيح.

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

بعد توليد YANG يقدم RFC 7950 دلالات قوية لـmust وwhen وleafref وaugment والـfeatures وقيود الحالات. ويمكن للمدقق، عند تزويده بإغلاق الوحدات الكامل والـdeviations وحالات اختبار ناجحة وفاشلة، أن يقدم دليلاً قوياً محدوداً. لكنه لا يعرف إن تحولت عبارة طبيعية إلى XPath المقصود، أو إن كان الخادم يملك الـaugment، أو إن كان المستخدم مفوضاً. ويقدم RFC 8407 إرشادات تصميم، لا شهادة تبنٍّ.

تسجل YANG Library في RFC 8525 ما يعلنه الخادم من وحدات وfeatures وdeviations. ويجب وصل هذا الإعلان ببايتات المصدر ومسار حل العميل وبصمة المخطط الفعال. ثم يفصل RFC 8342 بين الحالة intended وoperational: قبول الإعداد لا يثبت تطبيقه أو أثره. وحتى RFC 8259 لا يمنح JSON السليم شهادة بصحة الواقع الذي يصفه.

تقول NAIM إنها ليست ترميز JSON لـYANG ولا بديلاً عنها. كما تحيل نيات التشغيل إلى مسودة مستقلة هي NAIM-OP. ولا تحدد المراجعة 01 نموذج الذكاء الاصطناعي أو الـprompts أو درجات الثقة أو التنفيذ الفعلي.

ينبغي أن يحتفظ ادعاء الإنتاج بسلسلة تراكمية: الطلب وغموضه؛ JSON الدقيق ومصدره؛ العرضان والحذف والتعارض؛ YANG وإغلاقه واختباراته؛ تصريح الخادم وحل العميل والتفويض؛ ثم مشاهدات intended وoperational والقياس والتراجع والنتيجة.

تساعد فكرة Lu Heng عن الطبقة المشتركة الحتمية الدنيا على قراءة قيمة NAIM من دون توسيع سلطتها. كما تفصل ملاحظتاه عن أولوية الشفرة العاملة وطبقات الواقع بين الوثيقة والأثر التنفيذي. هذه عدسة BTW، وليست ادعاء بأن Lu Heng راجع المسودة.

المصادر