الخلاصة

  • تقترح draft-fedyk-netmod-yang-normal-form-00 حفظ التمثيل المعجمي الأصلي للسلسلة، مع اشتقاق صيغة حتمية للمساواة ومفاتيح القوائم وتفرّد leaf-list الخاص بالإعدادات.
  • في مثال MAC، تؤدي النقطتان أو الشرطات، والأحرف السداسية الكبيرة أو الصغيرة، إلى قيمة مقارنة واحدة من 12 خانة. يتحقق pattern من البنية، لكنه لا يجعل سلسلتين مقبولتين متساويتين.
  • يسجل Datatracker الوثيقة بوصفها Internet-Draft فردية نشطة، بلا intended RFC status، وبحالة IESG هي I-D Exists. أما ترويسة النص فتقول Intended status: Standards Track. لا يثبت ذلك تبني NETMOD أو تأييد IETF.

إبقاء الكتابة وفصل معيار المساواة

قد يمثل نظامان عنواناً واحداً من 48 بت بنصين مختلفين. يستعمل نوع IETF الشائع في RFC 6991 ومراجعته الحالية RFC 9911 ستة ثمانيات مفصولة بنقطتين ويصف الأحرف الصغيرة بأنها canonical. ويستعمل نوع IEEE المعروض في مواد IETF الشرطات ويصف الأحرف الكبيرة. يدرك المهندس أنه عنوان واحد، لكن string key يرى رموزاً مختلفة.

تفصل المراجعة 00 بين العرض والمقارنة. تبقى القيمة المعجمية المستلمة للترميز والاسترجاع. ويحدد امتداد اختياري اسمه normalized-form خوارزمية حتمية تستخدم نتائجها في = و!= وتفرّد مفاتيح القائمة وleaf-list القابل للتهيئة.

تتحقق خوارزمية mac-48 أولاً من الإدخال وفق نوعه، ثم تزيل الفواصل وتحول الخانات السداسية إلى الأحرف الكبيرة وتستخدم الخانات الاثنتي عشرة المتبقية. لذلك تعطي aa:bb:cc:dd:ee:ff وAA:BB:CC:DD:EE:FF وaa-bb-cc-dd-ee-ff وAA-BB-CC-DD-EE-FF القيمة AABBCCDDEEFF. تعرض المسودة النتيجة بصيغة 0xAABBCCDDEEFF، لكن الهوية ذات 12 خانة هي الجزء من دون البادئة.

لا يكفي توسيع التعبير النمطي. يعرّف RFC 7950 pattern بوصفه قيداً على السلاسل المقبولة. والصيغة canonical للنوع string المدمج هي تمثيله المعجمي نفسه، بلا Unicode normalization. قبول حالتين للأحرف أو فاصلين لا يعرّف المساواة بينهما.

قراران مختلفان للتكرار

دعم الامتداد اختياري. على التنفيذ الذي يعلن دعمه أن يستخدم الصيغة المطبّعة، بينما يستمر غير الداعم في معالجة النوع المعجمي. وهذا يوافق قاعدة YANG 1.1 التي تجيز تجاهل امتداد مجهول كاملاً، وتلزم بمعالجة الامتداد المدعوم وفق مواصفته.

إذا كانت aa:bb:cc:dd:ee:ff موجودة ووصلت AA-BB-CC-DD-EE-FF إلى عقدة يسمح نوعها بهذه الصيغة، فقد يرفض التنفيذ الداعم الإدخال الثاني باعتباره المفتاح المطبّع نفسه. وقد يراه غير الداعم سلسلتين. يظهر الفرق في XPath والقوائم ذات المفتاح وleaf-list الخاص بالإعدادات.

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

ثلاث حقائق لازمة لوصف الحالة

تعرض صفحة Datatracker active individual Internet-Draft، ولا RFC stream ولا intended RFC status، وحالة I-D Exists. كما تنبه إلى أن أي شخص يستطيع تقديم I-D وأن هذه الوثيقة لا تحظى بتأييد IETF ولا بمكانة رسمية في عملية المعايير. وفي المقابل تقول ترويسة النص الثابت Intended status: Standards Track وتنتهي صلاحيته في 2 يناير 2027.

الترويسة تسجل نية كتبها المؤلفان، أما Datatracker فيسجل الموقع الإجرائي الفعلي. وحتى كتابة «IETF NETMOD Working Group» في حقل organization داخل الوحدة لا تثبت تبني مجموعة العمل.

المؤلفان هما Don Fedyk من LabN Consulting وScott Mansfield من Ericsson. يسجل ملف Fedyk 24 RFC، ويسجل ملف Mansfield خمسة وواجبات liaison بين IETF وITU-T. الخبرة سبب للقراءة الدقيقة، وليست موافقة مؤسسية.

وتوضح شرائح NETMOD في IETF 124 أصل النقاش: صيغة واحدة، patterns أوسع، آلية تكافؤ، تخزين مختلف، أو عدم التغيير. تختار المراجعة 00 هوية مقارنة منفصلة مع الاحتفاظ بالصيغة الأصلية.

ما الذي تثبته المساواة فعلاً

تثبت الصيغة المطبّعة المتساوية أن مدخلين مقبولين عبرا التحويل المعلن نفسه. وتثبت نتيجة XPath كيف قيّم تنفيذ معين تعبيراً في سياق schema محدد. ويثبت الرفض أن قيد إعداد محلياً قد فُعّل.

لا يثبت ذلك جهازاً مادياً واحداً، ولا خلو خوارزميات أخرى من التصادم، ولا تطابق تنفيذين أو دعم الطرفين. كما لا يثبت schema وشجرة XPath متطابقتين، أو ترحيل datastore، أو القصد أو التفويض أو إزالة التكرار من forwarding state أو نتيجة الشبكة.

هذا يختلف عن canonicalization العادي. ينتج XDR تمثيلاً خارجياً واحداً للبايتات؛ أما هنا فتبقى صيغ معجمية متعددة وتتحكم هوية موازية في بعض المقارنات فقط. ولا يثبت اسم الوحدة الصحيح أو schema diff أن الخوارزمية قد نُفذت.

السؤال التشغيلي محدود: أي دليل يثبت أن المحرك قارن القيمة المعلنة لا شكل كتابة السلسلة؟