الخلاصة

  • يربط draft-toutain-t2trg-coreconf-m2m-01 نموذج YANG/SID مضغوطاً بـ ontology وFROST وأدوات MCP يمكنها قراءة أجهزة مقيدة أو إعدادها.
  • تعريف الأداة وSID الصحيح والقناة المحمية والاستجابة الناجحة أدلة لطبقات مختلفة؛ ولا يثبت أي منها وحده أن المستدعي مخوّل بتحريك actuator أو أن الحالة الفيزيائية المطلوبة تحققت.
  • يجب أن يربط الإيصال القابل للدفاع إصدار النموذج وإسقاط الهوية والـprincipal والسياسة والموافقة والطلب وقرار CORECONF والتحقق المحلي والحركة وقراءة لاحقة مستقلة.

يمكن للنموذج أن يرى أداة باسم واضح، ومدخلاً مضبوطاً بوحدة وسقف، وزراً واحداً لتنفيذ الأمر. لكن الجهاز في الطرف الآخر لا يرى هذه القصة. يرى bytes وهوية أمنية وSID وسياسة محلية وحالة interlock. وبين الواجهتين توجد بوابة لا يجوز أن يملكها اسم الأداة.

هذه البوابة هي موضوع المسودة بقدر ما هي موضوع غائب عنها. ففي 2 أكتوبر 2026 أدرج IETF Datatracker المراجعة 01 من CORECONF for Machine-to-Machine Communication كمسودة إنترنت فردية نشطة، محدثة في 16 سبتمبر. النص مؤرخ في اليوم نفسه، يستهدف Informational وينتهي في 20 مارس 2027. لا يوجد RFC stream أو AD مسؤول أو telechat. ويؤكد Datatracker أن التقديم الفردي ليس تأييداً من IETF ولا يتمتع بمكانة رسمية في مسار المعايير. أما النقاش في قائمة T2TRG فلا يثبت اعتماد IRTF.

أظهر فحص YANG في التاريخ نفسه 19 خطأ و8 تحذيرات. شملت النتائج مراجع مفقودة للمراجعات، أوصافاً ناقصة، ترتيباً غير canonical، وتحذيراً من أن bootstrap ذي config false ليس في الشجرة المتاحة. هذه قرائن نضج للإصدار المقدم، وليست عدداً للثغرات ولا دليلاً على فشل نشر حقيقي.

تختفي طبقة مخصصة، ولا تختفي سلطة التفسير

تجمع المسودة YANG للبنية، وCBOR للحجم الصغير، وCoAP للنقل، وSID لاختصار أسماء عناصر المخطط إلى أرقام. وتستخدم transducer اسماً جامعاً للحساس والمشغّل أو للجهاز الذي يؤدي الوظيفتين. يحمل النموذج القيمة والوقت ومصدره والإحصاءات وإعدادات الإشعار.

تضيف المراجعة 01 إسقاطاً إلى SOSA وSensorThings، ثم تصف خادمين MCP. يتعامل coreconf-m2m مع الجهاز الحي عبر CoAP، ويتعامل frost-sensorthings مع المعلومات التاريخية والعلاقات في FROST. في مثال Rennes يبحث الوكيل عن Thing، يتبع Datastreams، يحصل على sensor SID وprecision، يقرأ القيمة ثم يخزن Observation.

يقول الملخص إن هذا يسمح بالتشغيل البيني بلا طبقة ترجمة خاصة بالجهاز. الفائدة حقيقية: لا حاجة إلى serializer يدوي لكل منتج. لكن الخادم ما زال يفسر hostname وendpoint وهوية transducer وinstance SID وtarget SID والوحدة والدقة من قاعدة بيانات. إنه وسيط دلالي حتى لو لم يكن adapter مخصصاً.

قد يوجه endpoint قديم الطلب إلى جهاز استبدل. وقد تربط هوية معاد استخدامها اسماً جديداً بمتحكم قديم. وقد يحول precision خاطئ عدداً صحيحاً إلى مقدار مادي خاطئ. وقد توسع category معدلة سطح الكتابة. تظل الحزمة صحيحة نحوياً في كل هذه الحالات.

لذلك يحتاج إيصال الإسقاط إلى YANG module/revision والـfeatures والـdeviations وملف SID وأي private translation وهوية الجهاز وtransducer وجيل bootstrap والـendpoint والوحدة والدقة والفئة ونوع control والطريقة والمسار وtarget SID وإصدار سجل FROST ومصدره وحداثته.

إعلان control ليس تفويضاً

تمثل ccm2m:Control عمليات مثل read-single وread-stat ومسح الإحصاءات وإعداد history والاشتراك وinstant-write. ويفصل النص جيداً بين تهيئة الإشعار وبدئه، ويضع الإيقاف في دورة Observe لا في SID جديد.

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

المسودة الأساسية CORECONF revision 21 تشترط أن يمنع الخادم المستخدمين غير المخولين من القراءة أو الكتابة. وهي تعرف 4.01 Unauthorized عندما لا يملك client إذناً على data node أو datastore أو RPC أو action أو event stream، وتطلب آليات مناسبة للمصادقة والتفويض. لذلك لا يصح القول إن CORECONF بلا authorization.

وتحافظ مواصفة MCP 2026-07-28 على الفصل نفسه. يمكن أن تختلف قائمة الأدوات بحسب authorization المقدم مع كل طلب. وعلى الخادم التحقق من المدخلات وتطبيق access control وrate limit، وعلى العميل طلب confirmation في العمليات الحساسة وعرض المدخلات والتحقق من النتائج. كما أن tool annotations غير موثوقة إذا لم يأت مصدرها من server موثوق.

العمل الضروري هو الربط بين الطبقات. يجب أن يجمع السجل هوية خادم MCP وhash تعريف الأداة والعميل الطالب والprincipal المصادق عليه وaudience وscopes والسياسة والموافقة والهدف وحدود القيمة مع قرار CORECONF. اسم الأداة يصف فعلاً؛ لا يثبت سلسلة التفويض.

حماية القناة لا تحرك العالم

تشترط المسودة DTLS أو OSCORE لعمليات CORECONF فوق CoAP. هذا يحمي الاتصال حسب profile المستخدم، لكنه لا يضع حدود سرعة مضخة ولا يقرر إن كان وقت الصيانة يسمح بفتح valve. يمكن للتشفير أن يسلم أمراً غير مسموح بأمان كامل.

يفصل CORECONF بين Unauthorized وNot Found وMethod Not Allowed وأخطاء قيود YANG. ويثبت الرد الناجح أن الطلب عولج في تلك الطبقة، لا أن العمود دار أو أن الضغط استقر.

يوضح النص instant-write بمضخة خيالية تضبط على 1500 rpm. يستعمل PPPPPP كـplaceholder لهوية لا وجود لها في النموذج، بينما SID البنيوي للكمية حقيقي. تسجل sosa:Actuation القيمة المكتوبة ووقت إصدار الأمر، ويصرح النص بأنها command لا Observation.

هذه الجملة هي الحد الصحيح. الأمر ليس قراءة tachometer. ويحتاج التأكيد اللاحق إلى sensor مستقل وهوية ومعايرة ووحدة ودقة ومصدر وقت ونافذة سببية. قراءة cache الذي كتب فيه الأمر تعيد النية ولا تقيس الحركة.

السلم الكامل يفصل invocation، والنية والموافقة، والprincipal والتفويض، والطلب المحمي، والتحقق التطبيقي، والـcommit أو بدء action، وحالة interlock، والتنفيذ المادي، والقياس المنفصل، ودوام الحالة، ثم reconciliation أو rollback. يجوز أن تتوقف السلسلة، لكن يجب إظهار موضع التوقف.

الإعداد المشترك يكشف مدى التأثير

إعدادات notification مثل step وprecision وmax-samples وtime-period وencoding وmax-payload والحدود وhysteresis وdampening وcheck-interval قابلة للكتابة. وهي مشتركة بين كل observations الخاصة بـtransducer واحد. إذا تغيرت أثناء نشاط الإشعار، تأثر كل clients فوراً بغض النظر عن الطرف الذي غيّرها.

أداة start_history_notify تجري iPATCH للإعداد ثم FETCH+Observe. ما يبدو اشتراكاً شخصياً قد يغير cadence أو encoding أو confirmation لمراقبين موجودين. ويخبر active أن مراقباً واحداً أو أكثر موجود، لكنه لا يحددهم ولا غرضهم ولا موافقتهم.

ينبغي للأداة الآمنة أن تكشف shared scope، وتقرأ الإصدار والقيمة السابقة، وتستخدم precondition أو conflict rule، وتحفظ before/after ومن تأثر. إذن subscribe ليس إذن إعادة إعداد الآخرين. وإذن قراءة FROST ليس إذن تعديل خريطة الهوية التي يستخدمها المسار الحي.

رسائل NON تنقل الغموض إلى التطبيق

يفرض profile إرسال FETCH وiPATCH كرسائل CoAP Non-Confirmable. يخفف ذلك عبء retransmission على الروابط محدودة الطاقة، لكنه يجعل timeout وretry وidempotency مسؤولية التطبيق.

عند غياب الرد لا يعرف MCP server هل ضاع الطلب، أم طبق الجهاز الطلب وضاع الرد، أم لا تزال العملية جارية. قد يكون تكرار set-value آمناً، بينما يكون تكرار action ذات side effect خطيراً. يحتاج الإيصال إلى request identity وtoken وpayload hash ورقم المحاولة وسياسة الوقت وسلوك duplicate وreadback لاحق.

أما ACK لإشعار Confirmable فيثبت وصول الرسالة إلى peer CoAP. لا يثبت التخزين الدائم في FROST أو انتباه agent أو الإنسان أو انتهاء الحالة الفيزيائية.

الزمن والوحدة جزء من النتيجة

قد يحتوي bootstrap على reference epoch وuptime وminimal-step، وقد يغيب الوقت المطلق. ويكون timestamp للقيمة من source أو receiver، فيما يعاد بناء أوقات history أحياناً من الوصول وstep. وقت الأمر وقبول firmware والحركة والتخزين ليست لحظة واحدة.

لا يصبح العدد الخام مقداراً مادياً إلا مع identity وunit وprecision. والاستعلام أسرع من minimal-step قد يستنزف البطارية من دون عينة أحدث. لذلك يحمل postcondition إصدار النموذج والمقياس والمعايرة ومصدر الزمن وجودة الساعة والعمر.

وينتمي رقم 19/8 إلى إيصال النموذج فقط. يشير إلى عمل مطلوب في هذه المراجعة. ولو أصبح صفراً لاحقاً فلن يثبت authorization أو interoperability أو الحركة. قبول validator ليس شهادة سلامة.