الخلاصة

  • تظل draft-dogru-cedulon-decision-profile-02 المؤرخة في 5 سبتمبر 2026 مسودة Internet-Draft فردية نشطة بلا تأييد أو مكانة رسمية لدى IETF، وبلا مسار RFC أو Area Director مسؤول.
  • يوفق الملف بين Decision Records موقعة وصفوف Effect Extract موثقة. يتوقع قرار السماح أثراً واحداً، بينما لا يتوقع الرفض أو التأجيل أي أثر.
  • تقول المراجعة 02 صراحة إن الربط لا يرتب الساعتين. يفحص توقيت الصف داخل نافذة الاستخراج، ولا يقارنه بتوقيت Decision Record المقابل.
  • يثبت effect-against-refusal أن رفضاً وأثراً بالمرجع نفسه موجودان في المجتمع المدقق، لكنه لا يثبت وحده أن الأثر جاء لاحقاً ولا يحدد موضع فشل التحكم.
  • ينبغي لإيصال مستقل عن التسلسل أن يسمي سلطة كل ساعة وهامش الخطأ والأدلة المساندة، ثم يحفظ حالات: قبل، بعد، ضمن الهامش، أو غير محدد.

ما الذي يثبته عدم الاتزان؟

تحدد صفحة Datatracker الوضع المؤسسي قبل الدخول في التقنية. النص هو المراجعة 02 من مساهمة فردية كتبها Emek Can Doğru وحُدثت في 5 سبتمبر. يمكن لأي شخص تقديم I-D، وهذه الوثيقة ليست مؤيدة من IETF ولا تملك وضعاً رسمياً في عملية المعايير. لا يوجد RFC stream أو Responsible AD أو تاريخ telechat، وحالة IESG هي «I-D Exists» فقط.

يقارن المقترح مجموعتين محددتين. يوقع صاحب القرار Decision Record يقول إن كان مسموحاً للوكيل أن يتصرف. ويوفر المشغل أو عملية الالتقاط Effect Extract موثقاً لما حدث فعلاً على قناة واحدة داخل نافذة زمنية. يعمل المدقق على صاحب قرار واحد وقناة واحدة ونافذة معلنة.

يتطلب قرار السماح صفاً واحداً يحمل المرجع نفسه وhash المحتوى وفئة الأثر نفسيهما. غياب الصف يصبح decision-without-effect. الصف الذي لا يقابله قرار يصبح effect-without-decision. أما deny وdefer فيعدان رفضاً لا يتوقع صفاً؛ فإذا ظهر صف تحت المرجع نفسه كان الاكتشاف effect-against-refusal.

يميز هذا الاسم الحالة عن أثر لم يسبقه أي قرار، وهي فائدة حقيقية للتحقيق. لكن النص المؤرشف للمراجعة 02 يمنع قراءة الاسم كدليل تلقائي على أن الأثر حدث بعد الرفض.

النافذة لا ترتب السجلين

يحمل كل من Decision Record وصف الأثر timestampMs. ومع ذلك لا يضع المدقق الرقمين في مقارنة مباشرة. يجب أن يقع توقيت الصف داخل [windowStartMs, windowEndMs)، لكنه لا يلزم أن يكون لاحقاً لتوقيت القرار المرتبط به. تقول المراجعة بوضوح إن صفاً مؤرخاً قبل السجل يرتبط كما لو أنه جاء بعده. المقارنة تخص المرجع والمحتوى والفئة، لا التسلسل.

لو سجل الأثر عند 10:00 وسجل الرفض عند 10:01، فقد يصدر effect-against-refusal أيضاً. ربما سبق الأثر الرفض فعلاً، أو تقدمت إحدى الساعتين، أو اتخذ القرار مبكراً ووقع لاحقاً، أو أضافت عملية الالتقاط التاريخ بعد الواقعة. يبقى اختلاف المجموعتين قابلاً للإثبات، بينما يبقى ترتيب التاريخ غير محسوم.

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

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

لا تحول المطابقة إلى حكم على السلوك

ينبغي الإبقاء على effect-against-refusal بوصفه نتيجة حفظ. هناك أثر تحت مرجع تسميه مجموعة القرارات رفضاً. هذا أدق من إنذار عام ويستحق متابعة.

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

قد تؤثر هذه الإضافة في تصعيد حادث أو مسؤولية عقدية أو إجراء وظيفي. لذلك لا يجوز إخفاؤها في وصف آلي. يقدم مبدأ Heng Lu في دقة السجلات قيداً تحريرياً مفيداً: السجل يصف الواقع ولا يخلقه. هنا يستطيع التوفيق وصف القرارات والآثار والمقارنات التي نفذها؛ ولا يستطيع خلق ترتيب لم يقسه. هذا تطبيق تحليلي من Daniel Kade، وليس قاعدة من IETF أو Cedulon.

إيصال زمني يحافظ على أربعة احتمالات

لا يلزم تغيير النتيجة الحالية. يمكن للزوج نفسه أن يحمل effect-against-refusal وsequence-indeterminate في آن واحد. الأولى تخبرنا عن المجموعتين، والثانية عن قوة الدليل الزمني.

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

بعد ذلك تكفي أربع نتائج:

  • قبل عندما يسبق الأثر الرفض خارج مجال عدم اليقين؛
  • بعد عندما يتبعه خارج المجال نفسه؛
  • ضمن الهامش عندما لا ينجو الفرق العددي من الانحراف المعلن؛
  • غير محدد عندما لا تدعم المنشأ أو المزامنة المقارنة.

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

على الكود العامل أن يحفظ الشك

تقول فقرة Implementation Status، وفق إطار RFC 7942، إن مستودع المؤلف المصاحب يحمل عشرين حالة conformance وأربعة fixtures بلا اتصال. كما تسجل حدودها: تغير المراجعة 02 النص ولا تضيف حالة؛ ترتيب الساعتين مذكور ولا يطبق. لم يُقس سجل قناة حي، ولا يُعرف تطبيق مستقل، ولا يوجد التزام زمني مسبق للتواريخ العامة المكتوبة بعد الواقعة.

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

المصادر

  1. IETF Datatracker: Cedulon Decision Profile
  2. أرشيف IETF: draft-dogru-cedulon-decision-profile-02
  3. مستودع Cedulon المصاحب
  4. IETF Datatracker: مسودة Cedulon الأساسية
  5. RFC 7942: Improving Awareness of Running Code
  6. RFC Editor: How RFCs Are Created
  7. Heng Lu: The Bill of Rights of Uniqueness Coordination