الخلاصة

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

وصل طلب تعديل عبر قناة إدارة موثقة. ينتمي صاحبه إلى مجموعة يسمح لها بتحديث الإعدادات، ويعرض الحقل المستهدف القيمة change-tv. أمام نظام آلي، يبدو أن شرطين إيجابيين قد اكتملَا وأن التنفيذ يمكن أن يبدأ.

لكن الشرطين يجيبان عن سؤالين مختلفين. سياسة الجلسة تقول إن هذا الفاعل يستطيع طلب نوع من عمليات الإدارة. ورقة SCHC تقول إن هذا الـ Field Descriptor يقبل نوعاً من التغيير. لا يقول أي منهما وحده إن هذا الفاعل يملك هذا Context أو هذا RuleID، ولا إن النسخة التي قرأها ما زالت الحالية، ولا إن الطرف الآخر سينتقل إلى المعنى الجديد في الوقت نفسه.

هذا مشهد تحليلي معاد البناء، وليس حادثة منشورة. وهو يكشف الحد الذي ينبغي أن نقرأ ضمنه draft-ietf-schc-access-control-01: قابلية الشيء للتعديل خاصية في الشيء، أما سلطة التعديل فتحتاج إلى فاعل وسند مستقلين.

ما يحذفه الضغط يجب أن يبقى متفقاً عليه

يختصر SCHC الرؤوس لأن الطرفين يشتركان في Context سابق. وفق RFC 8724، يشير RuleID إلى قاعدة يعرفها الضاغط وفاك الضغط. وتضم أوصاف الحقول Field Identifier وTarget Value وMatching Operator وCompression/Decompression Action وغيرها.

كل بت لا يُرسل يتحول إلى اعتماد على الاتفاق المخزن. إذا اختلف معنى RuleID بين الطرفين، فلن تحمل الحزمة المختصرة نسخة كاملة تصلح الخلاف. يحذر RFC 9363 من أن تغيير عنوان IPv6 للتطبيق قد يوقف الاتصال أو يتيح التنصت، ولذلك يطلب التحقق من هوية الطالب وقصر الجهاز على تعديل قواعده هو.

يعالج المشروع الجديد نقصاً آخر: إذ لا تكفي صلاحية عامة لكتابة شجرة YANG. قد يكون تغيير Target Value الخاص بـ Uri-Path مقبولاً، بينما يجب أن يبقى بادئ التطبيق في القاعدة نفسها ثابتاً. لذا يلزم حد مرتبط بدلالة العنصر، لا مجرد حق كتابة واسع.

ثلاث طبقات تعمل كسقف واحد

تحدد ac-modify-set-of-rules ما إذا كانت مجموعة القواعد ثابتة، أو تسمح بتعديل عنصر موجود، أو تسمح بالإضافة والحذف. وتضيق ac-modify-compression-rule المجال داخل قاعدة الضغط. ثم تفصل ac-modify-field بين عدم التغيير، وتغيير Target Value، وتغيير TV مع MO وCDA.

لا يجوز قراءة الابن بعيداً عن الأبوين. لا تصبح ورقة قاعدة الضغط فعالة إلا إذا سمح المستوى الأعلى بالتعديل. ولا تصبح ورقة الحقل فعالة إلا إذا سمح الأبوان. قيمة change-tv في الأسفل لا تتجاوز no-change في الأعلى. وإذا غابت الورقة، ينص المشروع على عدم جواز تعديل المعلومة.

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

مع ذلك، لا تحتوي الأوراق على principal أو username أو group أو credential أو session أو owner أو delegation. إنها تصف شكل التغيير الأقصى الذي يتحمله العنصر. ولا تسمي من يحق له الوصول إلى ذلك الحد.

هوية الفاعل تأتي من طبقة الإدارة

لا يرفض المشروع NACM، بل يوضح أن NACM يسمح للمستخدمين والمجموعات بأفعال محددة، وأن دقته العامة لا تكفي لبنية قاعدة SCHC. يربط RFC 8341 اسم مستخدم موثقاً ومجموعات بجلسة، ويختبر عمليات البروتوكول وعقد البيانات، ويرد بـ access-denied عند الرفض. كما يثبت مجموعة قواعد الوصول طوال معالجة الرسالة الواحدة.

إذن يجب أن يكون القرار تقاطعاً:

هذا الفاعل مخوّل بتنفيذ هذا الطلب و هذا العنصر في SCHC يقبل هذا النوع من التغيير.

يستطيع NETCONF، إذا أعلن الخادم القدرات المناسبة، أن يوفر التحقق وcandidate datastore والقفل وrollback-on-error. ويستطيع RESTCONF استعمال ETag وIf-Match لرفض كتابة تستند إلى نسخة قديمة. أما CORECONF فيقدم إدارة YANG مختصرة فوق CoAP ويلزم الخادم بمنع القراءة والكتابة غير المصرح بهما مع اختيار حماية وتفويض مناسبين.

هذه الأدوات مكملة لا بديلة. نموذج CRUDX في NACM لا يصف وحده لماذا يمكن تغيير TV بينما يبقى بادئ مجاور محمياً. وقيمة change-tv لا توثق أي مستخدم. الاكتفاء بالأولى قد يجعل دور الإدارة الواسع يبتلع حدود الحقول، والاكتفاء بالثانية يحول الإذن إلى تذكرة بلا اسم.

نجاح الكتابة لا يعني نجاح الانتقال

حتى مع صحة التفويضين، قد يكتب متحكمان اعتماداً على الحالة القديمة نفسها. يساعد ETag في RESTCONF على كشف ذلك، ويستطيع قفل NETCONF أو candidate datastore توفير عزلة وتحقيق مختلفين. لا تفرض المراجعة 01 تركيبة واحدة لهذه الضوابط.

ثم يأتي الفرق بين datastore والبروتوكول. قد يقبل الخادم التعديل ويرد 204 أو <ok/> بينما يستمر الطرف الآخر في تفسير RuleID وفق Context السابق. إيصال الإدارة يثبت معاملة كتابة. ولا يثبت أن المعنى المشترك انتقل بأمان.

يلزم لذلك تسجيل النسخة السابقة والجديدة، وحد التفعيل الزمني، والأطراف المتأثرة، ودليل التوافق، ونقطة رجوع مجربة. وإلا فقد يتحول نجاح في control plane إلى اختلاف خفي في data plane.

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

علامات عدم الاكتمال هي جزء من الدليل

المراجعة 01 Internet-Draft نشط ضمن مجموعة SCHC، محدث في 29 سبتمبر 2026، ويحمل ترويسة Standards Track، لكنه ليس RFC. ما زال قسم Terminology يحتوي ToDo، وقسما Security Considerations وIANA Considerations يحتويان TBD. ويحمل نموذج YANG مراجعة من 2023 ونصاً غير متعلق بالموضوع عن compound-ack وRFC YYYY، كما تصف قيم field access نفسها بأنها Reserved slot number.

هذه العلامات لا تبطل فكرة الهرم. لكنها تمنع تحويل الأسماء والدلالات الحالية إلى عقد منتج نهائي. ويؤكد مشروع معمارية SCHC الصادر في يوليو 2026 أهمية سلامة Context وتوثيق المديرين وتفويضهم وتدقيق التغييرات والقدرة على استعادة نسخة سليمة، مع إقراره بأن lifecycle وmanagement ما زالا قيد التطوير.

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

إيصال يربط السلطة بالنتيجة

ينبغي أن يحفظ كل تغيير مهم:

  1. الفاعل الموثق والمجموعات والجلسة وحماية النقل؛
  2. العملية وContext وSet of Rules وRuleID المستهدف؛
  3. النسخة السابقة أو ETag والقيم الدقيقة قبل التغيير وبعده؛
  4. كل أوراق SCHC ذات الصلة، بما فيها الآباء؛
  5. مراجعة سياسة NACM أو ما يعادلها؛
  6. نتيجة التحقق وفحص التعارض والمعاملة؛
  7. وقت التفعيل ودليل التوافق لكل peer؛
  8. الأثر المرصود والمسؤول ونقطة rollback المختبرة.

السلطة المحدودة لا تعني منع كل تغيير. بل تعني ألا تدعي طبقة أكثر مما تستطيع إثباته: الهوية تثبت الفاعل، وSCHC يحد العنصر، والمعاملة تحمي الكتابة، والمشغل يملك قرار التفعيل. وجودها في نداء API واحد لا يدمج تفويضاتها.

Sources