الخلاصة

  • يجيز RFC 9752 حمل Vendor Information Object في رسائل PCRpt وPCUpd وPCInitiate، ويربط Enterprise Number صراحة بسجل IANA للأرقام المؤسسية الخاصة.
  • صحة PEN تثبت موضعاً في namespace خاصاً، ولا تثبت ناشر الدلالة أو إصدارها أو دعم المستقبل أو تفويض تغيير الحالة أو ما ثبته الجهاز.
  • السجل القابل للتدقيق يصل البايتات والـdecoder باتفاق القدرة والقرار المحلي ومعرّفات SRP/PLSP ومصالحة PCE/PCC والجهاز والتحويل وحركة المرور والتراجع والبديل المشترك.

قد تبدو العملية كاملة من شاشة واحدة: جلسة TLS قائمة، PCUpd وصل، PEN معروف، ثم عاد PCRpt. لكن هذه الشاشة جمعت أربعة إيصالات مختلفة تحت لون أخضر واحد. لا يظهر فيها إصدار الوثيقة الخاصة، ولا هوية ناشرها، ولا سبب سماح PCC بالعملية، ولا قراءة مستقلة من FIB أو من الحزم الفعلية.

نُشر RFC 9752 في أبريل 2025 بوصفه Proposed Standard من IETF. وتثبت بطاقة RFC Editor وسجل Datatracker أنه يحدّث RFC 7470. الإنجاز هو نقل معلومات المورّد إلى عمليات PCE ذات الحالة، لا إنشاء قاموس موحد لتلك المعلومات.

اقتراب الحاوية من تغيير الحالة

عرّف RFC 7470 كائن VENDOR-INFORMATION بالفئة 34 والنوع 1، وعرّف TLV بالنوع 7. يأتي بعد Enterprise Number ذي 32 بت محتوى يحدد تنسيقه وتفسيره الكيان الذي يشير إليه الرقم. قد ينشره في Informational RFC أو وثائق تجارية، لكن هوية تلك الوثيقة وإصدارها وhash الخاص بها لا تنتقل إلزامياً في الكائن.

يوسّع RFC 9752 مواضع الكائن. يرسل PCC رسالة PCRpt لوصف حالة LSP. ويرسل PCE رسالة PCUpd لطلب تغيير خصائصه. أما PCInitiate فيطلق إنشاء LSP أو حذفه، وتضع الصياغة الموسعة قائمة المورّد في صورة الإنشاء. وكان TLV قابلاً من قبل للوجود في SRP وLSP وغيرهما من الكائنات ذات الحالة التي تقبل TLV.

لكل موضع أثر مختلف. معلومة خاصة في تقرير لا تثبت أنها سببت الحالة، ومعلومة في طلب تحديث لا تثبت أنها طُبقت. ويمكن أن تحتوي PCRpt على أكثر من كائن بأرقام PEN مختلفة، من دون أن يحدد RFC 9752 قاعدة عامة للأسبقية أو لحل التعارض مع كائن قياسي.

سجل PEN لا يوقّع الحمولة

صحح RFC 9752 المرجع إلى سجل Private Enterprise Numbers الذي يصفه RFC 9371. تخصص IANA الأرقام بسياسة First Come First Served، وتتحقق من تفويض طلب تغيير قيد السجل. هذا دليل على إدارة القيد نفسه.

لكن RFC 9371 يقول أيضاً إن أحداً لا يستطيع منع طرف ثالث من وضع PEN يخص غيره في بياناته. لذلك لا يعمل الرقم كتوقيع على packet أو specification. كما لا يثبت أن فريق المنتج الحالي أو المالك بعد استحواذ أو fork هو الذي نشر المعنى المستخدم.

تحتاج الحضانة الدلالية إلى بيان منفصل: ناشر موثّق، إصدار دقيق، تاريخ وhash للوثيقة، hash للـdecoder، مواضع الرسائل المدعومة، تاريخ سحب ونهاية دعم. ويجب أن يبقى هذا البيان صالحاً عند الاندماج أو الانفصال أو توقف المنتج، لا أن يعتمد على اسم قديم في السجل.

معرفة الكائن ليست معرفة نسخته

إذا كانت implementation تعرف Vendor Information Object لكنها لا تدعم Enterprise Number الموجود، يطلب RFC 9752 تجاهله وفق القاعدة الموروثة. كما ينبغي ألا يرسله المتكلم إن كان يعتقد أن الطرف الآخر لا يدعمه. مع ذلك يترك RFC 7470 إعلان الأرقام والدلالات المدعومة خارج النطاق، ويقر بأن التشغيل الوظيفي بين مورّدين يحتاج اتفاق تعاون.

من ثم توجد أربع حالات: parser يفهم الغلاف؛ المنتج يتعرف إلى PEN؛ ينفذ إصداراً بعينه؛ والسياسة المحلية تسمح بهذا الإصدار لهذا peer وهذه الرسالة وهذا LSP. قد يحافظ ignore الصحيح على PCEP الأساسي لكنه يزيل الأثر الذي توقعه المرسل بصمت. وقد ينجح decode من دون أن تكون العملية مأذونة.

يجب أن يسمي إيصال capability الطرفين والإصدار والعمليات ومدة الصلاحية وقاعدة downgrade وfallback. ويُختبر المسار أيضاً بعد إزالة المحتوى الخاص ومع implementation أخرى. إذا تغير معنى الكائنات القياسية بصمت، فذلك اعتماد على مورّد لا interoperability.

هوية الجلسة لا تمنح إذن LSP

يوصي RFC 9752 بجلسة موثّقة ومشفرة وفق RFC 8253. تحمي TLS هوية الاتصال والبايتات أثناء النقل، لكنها لا توثّق ناشر القاموس الخاص ولا تمنح كل عملية صلاحية تلقائية.

يرسم RFC 8231 حد القرار: لا يعمل PCC بطلب تحديث LSP إلا إذا سمحت السياسة المحلية التي ضبطها مدير الشبكة. الطلب الذي عولج يبدأ setup وتتبعه حالة مبلّغة، ويمكن سحب delegation. ويطلب RFC 8281 إعلان capability للإنشاء من الطرفين ويفصل بين parameter غير مقبول وinternal error وsignaling error.

جلسة موثّقة، delegation، authorization، نتيجة parser، semantic validation وPCRpt ستة أدلة لا دليل واحد. تربط SRP-ID وPLSP-ID الطلب بالتقرير أو الخطأ، لكن تقرير PCC ليس قراءة مستقلة لـRIB أو FIB أو label table أو packet path.

المصالحة تمتد خارج PCEP

يبدأ الأثر بالبايتات الخام وPEN ونوع الرسالة وموضع الكائن وpeer وsession epoch. ثم يضيف specification وdecoder موقعين، الإصدار، parse disposition، الاختبارات الدلالية، قيم الكائنات القياسية، قاعدة التعارض، delegation والقرار المحلي. وتُربط PCUpd أو PCInitiate بـPCRpt أو PCErr من خلال SRP-ID وPLSP-ID والزمن.

بعد ذلك تأتي device transaction، وapplied configuration، والمسار أو الوسم المبرمج، واختبار الحركة، ونتيجة الخدمة، وrollback. وبعد restart أو resync أو timeout يعاد إثبات التطابق. قراءة FIB لحظة واحدة لا تضمن التسليم دائماً، واختبار packet واحد لا يثبت SLA.

لا يضيف RFC 9752 liveness جديداً ولا طريقة تحقق تشغيلية ولا مطلباً على بروتوكول آخر. يستطيع YANG قياسي إظهار وجود الكائن وPEN، لا التفاصيل الخاصة. ويحذر النص من covert channel ويطلب معرفة decoder وفحص المحتوى. عداد الوجود وحده يحذف أهم معلومة.

يثبت سجل PCEP لدى IANA codepoints. ولا تثبت المصادر deployment أو incident أو عيباً أو تحسناً لمورّد بعينه. تُستخدم أفكار Running-Code Primacy وMinimum Initial Specification وReality Layers لهينغ لو كإطار تحليلي معلن: تنسق الوثيقة الحاوية، أما التنفيذ والملاحظة فيثبتان الأثر. وليست تلك متطلبات IETF.