الخلاصة

  • تنتهي دعوة RATS لتبني draft-poirier-rats-eat-da-10 في 11 سبتمبر 2026. وهي تسأل هل يتولى الفريق مسودة فردية؛ وليست تبنياً مكتملًا ولا RFC ولا تعليمة نشر.
  • يستطيع Device Assignment Token نقل دليل عن جهاز. لكنه لا يختار القيود الإضافية، ولا يقيم الدليل، ولا يضع سياسة الطرف المعتمد، ولا يجيز استخدام الجهاز.

الدعوة تتعلق ببند عمل لا بجهاز مقبول

للموضوع العلني اسم وإصدار محددان: الإصدار 10 من An EAT Profile for Trustworthy Device Assignment. ما زال Datatracker يعرضه بوصفه Internet-Draft نشطاً ومرشحاً لعمل RATS، لا وثيقة أقرها IETF أو تتمتع بمكانة معيارية رسمية. والسؤال حتى 11 سبتمبر محدد: هل يعمل الفريق في هذا النص؟ قد يغير قرار لاحق حالة بند عمل، لكنه لا يشهد لمهايئ شبكة أو GPU أو وظيفة افتراضية في حمل عمل معين.

السياق مهم بالفعل. يتيح إسناد الجهاز لآلة افتراضية موثوقة أن تتحكم في مهايئ شبكة أو GPU أو وظيفة PCIe، فيما قد يكون برنامج المحاكاة أو الآلات الأخرى خارج حد الثقة الخاص بها. تطلب المسودة دليلاً عن هوية الجهاز وبرمجياته الثابتة وتهيئته، وتعرّف DAT بوصفه ملف EAT لتمثيل ذلك الدليل.

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

القيود الإضافية ليست داخل الرمز

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

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

ويقتضي النطاق الحالي التحفظ نفسه: التركيز على أجهزة PCIe المتوافقة مع SPDM، وترك أجهزة SPDM على الشريحة للنظر مستقبلاً، وعدم تغطية الترحيل الحي للآلة الافتراضية الموثوقة. لا يصح تسويق تنسيق يصرح بهذه الحدود كأنه حكم أمني عام لكل حالات الإسناد.

نتيجة المدقق ليست تفويضاً للطرف المعتمد

يفصل RFC 9334 بين تقييم الدليل، الذي يقوم به المدقق باستخدام قيم مرجعية وتأييدات وسياسة تقييمه، وبين تقييم نتائج الإقرار من الطرف المعتمد. يطبق الطرف المعتمد سياسته الخاصة ليصل إلى قرار خاص بالتطبيق، ومنه التفويض. ويمكن أن يملك أو يضبط هاتين السياستين مسؤولان مختلفان.

ويضيف RFC 9711 قيداً مهماً. يمكن لـ EAT أن يصف كياناً ليستعين به الطرف المعتمد في قرار الثقة، لكنه لا يضع قواعد معيارية لمعالجة المدقق. يجوز للمدقق أن يحيل الادعاءات أو يعدلها أو يضيف إليها وفق سياسته؛ وعلى الطرف المعتمد فهم تلك المعالجة قبل تفسير النتيجة. فتوقيع صحيح وملف سليم دليل على أثرٍ ما، لا أمر قابل للنقل يسمح بالجهاز.

ويتسق ميثاق RATS مع ذلك. فهو يشمل تنسيقات وإجراءات الدليل والنتائج ونقلها، ويستثني تنسيقات وبروتوكولات سياسة التقييم. هذا تقسيم مفيد: يسمح لتنسيق مشترك بالحركة من دون ادعاء أن فريق عمل يختار شهية المخاطر لكل مؤسسة.

إيصالان لمسؤوليتين

ينبغي أن يبقى الإيصال العام محدوداً وقابلاً للفحص: الدعوة وتاريخها والإصدار الدقيق ونطاق الملف وعبارة عدم فرض قيود إضافية والتعليقات وأي قرار لاحق. ولا يجوز تحويله إلى عبارة «وافق RATS على هذا الجهاز». وإلى جانبه يلزم إيصال قرار محلي يحدد الجهاز وسياق إسناده ومصدر الدليل وجذر الثقة المقبول وهوية المدقق وقواعده والقيم المرجعية والحداثة وإصدار السياسة ونطاق التفويض والمالك والرصد والرجوع.

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

المصادر

  1. دعوة RATS للتبني
  2. سجل Datatracker للمسودة
  3. draft-poirier-rats-eat-da-10
  4. ميثاق فريق RATS
  5. RFC 9334
  6. RFC 9711