الخلاصة

  • نُشرت النسخة -11 من draft-ietf-procon-2026bis في 1 يوليو 2026، وظلت في مرحلة المراجعة النهائية لمجموعة العمل في 27 أغسطس. وهي تحتفظ بآلية التباين الواردة في RFC 2026، لكنها ما زالت مشروع دمج وليست بديلاً معتمداً لـ BCP 9.
  • تستطيع مجموعة العمل المسؤولة — أو لجنة مخصصة عند غياب مجموعة مسؤولة — أن توصي باستثناء يخص مواصفة محددة عندما يقع انسداد أو لا تقدم الإجراءات إرشاداً. التوصية تفتح باب النظر ولا تمنح الموافقة.
  • على IESG أن يوازن القيمة التقنية والمسار العادي والبدائل والتكاليف والآثار الجانبية وآثار السابقة وإمكان تضييق النطاق. ويجب أن يظهر المقترح في Internet-Draft مستقل، وأن يخضع لـ Last Call ممتد لا يقل عن أربعة أسابيع، ثم يُعلن القرار؛ وإذا قُبل نُشر بصفة BCP، مع بقاء حق الطعن.
  • لا يجوز إسقاط المدد المحددة أو الانفتاح أو الإنصاف أو التوافق أو حفظ السجلات أو آليات إجرائية أساسية. لذلك يجب حفظ التباين كإيصال استثناء مرتبط بمواصفة واحدة، لا كتغيير ضمني للقاعدة أو إذن تلقائي للحالات اللاحقة أو إلزام للمشغلين بالتبني.

حين يتحول السجل من شاهد إلى مشرّع

الغرض من السجل أن يصف ما قررته المؤسسة. لكنه يستطيع، إذا اختصر القرار أكثر مما ينبغي، أن يصنع صلاحية لم تمنحها المؤسسة قط.

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

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

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

الحل هو فصل كيانين. القاعدة العامة لها نسخة وسريان وسند مستقل. أما التباين فله مواصفة مستهدفة ونسخة وبند وأسباب وتوصية ومراجعة وقيود وقرار وطعن. يمكن للقضية الماضية أن تغذي تحليل آثار السابقة، وهو تحليل يطلبه RFC 2026 صراحة، لكنها لا تحكم القضية الجديدة بذاتها. السابقة عامل يجب فحصه وليست مفتاحاً ينتقل تلقائياً.

هذا الفصل لا يلغي المرونة. القاعدة التي لا تسمح بمخرج قد تعجز أمام حالة لم تتوقعها. لكن المخرج الذي يغير القاعدة العامة بمجرد استعماله يهدم الاستقرار. الاستثناء المستقل يتيح الاجتهاد من دون أن يمحو حدوده.

وضع مشروع 2026bis كما هو، لا كما قد يصبح

تعرّف صفحة Datatracker الوثيقة draft-ietf-procon-2026bis-11 بوصفها Internet-Draft نشطة لمجموعة PROCON، لكن حقل Intended RFC status في الصفحة يظهر None، بينما تقول ترويسة نص المسودة إن الوضع المقصود Best Current Practice. يجب حفظ هاتين الحقيقتين منفصلتين. نُشرت النسخة -11 في 1 يوليو 2026، وتنتهي في 2 يناير 2027 ما لم تُحدّث أو تتقدم. ويبين سجل التاريخ أن المجموعة نقلت المشروع إلى Working Group Last Call في 21 مايو، حين كان في النسخة -08.

في 27 أغسطس ظل وضع مجموعة العمل In WG Last Call، بينما كان وضع IESG هو I-D Exists من دون موعد telechat. هذه قرائن على مشروع جدي وصل إلى مراجعة المجموعة. وليست قراراً من IESG ولا RFC منشوراً ولا BCP نافذاً.

إذا اعتُمد النص فسيدمج ويلغي عدداً من RFCs الإجرائية، بينها RFC 2026، وسيحدّث RFC 7475. تشرح وثيقة اختصاص PROCON السبب: أكثر من عشرين RFC عدلت الوثيقتين الأساسيتين RFC 2026 وRFC 2418، فتوزعت القواعد على سلسلة طويلة. مهمة المجموعة جمع السلسلة والأخطاء المصححة الموثقة في نصين أوضح. ولا تسمح الوثيقة إلا بمجالين مسميين من التغييرات غير التحريرية الإضافية؛ وما عداه يحتاج إلى إعادة تحديد الاختصاص.

تحتفظ المادة 11 من النسخة -11 ببنية التباين، لكنها لا تنشئ صلاحية جديدة في 2026. فقد نشرت RFC 2026، وهي جزء من BCP 9، البنية الأساسية نفسها في مادتها التاسعة سنة 1996. المشروع الجديد يعيد الدمج والترقيم ويحدّث بعض الألفاظ؛ ولا يصف سجل تغييره الآلية بأنها ابتكار سياسي جديد.

يجب أن يعرض سجل السياسات ثلاثة أوضاع معاً: RFC 2026 هي المرجع المنشور الحالي؛ و2026bis-11 اقتراح الدمج الذي ما زال قيد المراجعة؛ وإذا صدر RFC خلف لاحقاً، يتغير المرجع عند حدث النشر المنسوب بوضوح. استعمال المشروع لفهم اتجاه العمل جائز، أما معاملته كقاعدة نافذة فيقفز فوق القرارات التي لم تقع بعد.

التوصية ليست القرار

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

بعد التوصية، يقرر IESG ما إذا كانت المنفعة المرجحة لمجتمع الإنترنت تفوق كلفة عدم الامتثال. ولا يكفي أن تكون المواصفة جيدة تقنياً. يجب النظر في قيمتها التقنية، وإمكان تحقيق أهداف الإجراءات من دون تباين، والبدائل، والآثار الجانبية، وآثار السابقة، وقدرة القرار على أن يكون أضيق ما يمكن.

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

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

سلسلة علنية لحيازة القرار

يشترط RFC 2026 أن يحدد المقترح المشكلة المدركة والبند الدقيق الذي يسبب الصعوبة وتحليل IESG. ثم يصدر في شكل Internet-Draft مستقل، أي وثيقة علنية لها هوية ونسخ يمكن تتبعها.

بعد ذلك يعلن IESG فترة Last Call ممتدة لا تقل عن أربعة أسابيع. وعند انتهائها يتخذ قراره النهائي ويعلنه لـ IETF. وإذا وافق على التباين، يُحال للنشر بصفة BCP. وتظل إجراءات الطعن سارية.

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

تساعد RFC 7282 في قراءة التوافق التقريبي. ليس الأمر عدّاً للأصوات؛ فمضمون الاعتراض وكيف عولج أهم من النسبة. لا تجيب رسائل تأييد كثيرة وقصيرة تلقائياً عن اعتراض بنيوي واحد. وفي المقابل، وجود اعتراض لا يعني حق نقض آلياً. المطلوب سجل للحجة ومآلها.

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

أرضية لا يصل إليها الإعفاء

يمنع RFC 2026 التباين من خفض مدة محددة صراحة. كما يمنع الإعفاء من الانفتاح والإنصاف والتوافق، أو من واجب حفظ سجلات ملائمة للاجتماعات ونقاشات القوائم البريدية. ويحمي أحكاماً مركزية تتعلق بمراجعة BCP وبدء الإجراء ومراجعة IESG والنشر وتسوية التعارض والطعن وآلية التباين نفسها. يحمل 2026bis-11 هذه الأرضية إلى ترقيمه الجديد.

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

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

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

محتويات إيصال التباين

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

يحفظ قسم التحليل القيمة التقنية، وموازنة المنفعة والكلفة، والبدائل التي نوقشت ورُفضت، والآثار الجانبية وآثار السابقة، والنطاق الدقيق، وأي قيود إضافية. ويحفظ القسم العلني مسودة التباين وبصمتها، ووقت فتح Last Call وإغلاقه، والاعتراضات الجوهرية وكيف عولجت.

ثم يسجل قرار IESG وإعلانه، وهوية BCP إذا حدثت الموافقة، وحالة الطعون وقراراتها، وحد المرة الواحدة، وأي شرط انتهاء. وفي آخره عبارتان سلبيتان ضروريتان: لا يمنح هذا الإيصال إذناً لمواصفات لاحقة، ولا يثبت تبني أي مشغل أو نشره للتقنية.

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

الحد بين إجراء IETF وقرار التشغيل

يؤثر التباين في كيفية دخول مواصفة بعينها إلى مسار معايير IETF أو تقدمها فيه. ولا يقرر ما ينبغي لشركة أو مشغل أو حكومة أو مشروع برمجي أن ينشره.

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

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

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

المصادر