الخلاصة

  • يحدد RFC 8126 عشر سياسات للتسجيل في سجلات معاملات البروتوكول التي تديرها IANA؛ وفي اثنتين منها، Private Use وExperimental Use، لا تسجل IANA أي قيمة على الإطلاق.
  • ساعة الطعن ثابتة: يجب بدء الطعن خلال شهرين من العلم العلني. وساعة القرار غير ثابتة: «مدة معقولة» بلا أجل موحد، والقابلية للتوقع تُعرَّف بغياب الخطوات المفاجئة لا بعدد أيام موعود.
  • يستطيع IAB إلغاء قرار IESG واستعادة الوضع السابق، لكنه لا يستطيع اتخاذ قرار محفوظ لـ IESG، ولا يمنحه أي حكم مراجَع سلطة صريحة بالأمر بالتسجيل. وIESG هو نفسه الجهة التي تعيّن الخبير الذي يُطعن في حكمه، ويجوز لها إعفاؤه وفق تقديرها.

ابدأ بطلب لا بمبدأ. أحدهم يريد قيمة تُكتب في سجل معاملات بروتوكول تديره IANA. السجل وأسماء الحقول والسياسة المطبقة ثلاثة أشياء مختلفة، وإرشاد IANA نفسه، المعروض كمنقّح في 13 يوليو 2026، يقول ذلك بلا مواربة: نطاقات مختلفة داخل السجل الواحد قد تتبع إجراءات تسجيل مختلفة، فتسمية السجل لا تعني تسمية القاعدة (IANA, Guidance for RFC Authors). والصفحة نفسها تطلب تحديد السجل بدقة وتقديم معلومات الحقول المطلوبة، وتحذر من أن RFC المرجعي للسجل قد يفرض قالباً يحمل حقولاً لا تظهر في عرض السجل أبداً.

من يقرر فعلاً يحدده المستند لا العُرف. يضع RFC 8722، وهو وثيقة إعلامية لـ IAB صدرت في فبراير 2020، عمل مشغّل السجل في تسجيل المعاملات وفق المعايير والإجراءات المعرّفة في RFCs ووفق سياسة السجل المطبقة، مع إحالة الغموض إلى التوضيح (RFC 8722, §2.1). والوثيقة نفسها ترفع التقييم التقني عن كاهل المشغّل: «the Registry Operator will seek and follow technical guidance exclusively from the IESG»، والتقييم التقني عموماً ليس مسؤوليته (RFC 8722, §2.3). أما تعيين منظمة مشغّل السجل أو إنهاؤها فيعود إلى IAB بالعمل مع IETF LLC، وهو فعل منفصل عن تعيين الخبراء الأفراد (RFC 8722, §2.2).

قائمة السياسات مجموعة مغلقة من عشر. يسرد RFC 8126، الصادر في يونيو 2017، Private Use وExperimental Use وHierarchical Allocation وFirst Come First Served وExpert Review وSpecification Required وRFC Required وIETF Review وStandards Action وIESG Approval (RFC 8126, §§4.1–4.10). واثنتان من هذه الفئات تصمتان بالتصميم: قيم Private Use وExperimental Use لا تسجلها IANA إطلاقاً. ويضيف Specification Required إلى Expert Review شرطاً وثائقياً: مواصفة دائمة، متاحة للعموم، واضحة وسليمة تقنياً، وكافية لتمكين التشغيل البيني المستقل، وليست بالضرورة RFC (RFC 8126, §4.6).

حيث يملك السجل معايير منشورة، يطبّقها الخبير. وحيث لا يملك، يطلب RFC 8126 تقييم اكتمال الوثائق والتشغيل البيني والتعارضات، وافتراض الموافقة في غياب اعتراض قاهر (RFC 8126, §§5.1–5.3). وللرفض أسباب مسمّاة: ندرة المورد، ووثائق غير واضحة، وآثار معمارية أو نشرية ضارة، وتعارضات ضارة بعمل IETF، ولا يُذكر غيرها (RFC 8126, §5.3).

ثم الساعة. يكتب RFC 2026، الصادر في أكتوبر 1996 والذي ما زال شبكة الإجراءات الاحتياطية، هذا ويعنيه: «All appeals must be initiated within two months of the public knowledge of the action or decision to be challenged» (RFC 2026, §6.5.4). ويُلزم القسم نفسه من يقرر بالإجراء، ويوجب عليه أن يقرر ويبلّغ في مدة معقولة، ولا يقدم أي أجل ثابت موحد. ومبادئ IAB لتشغيل سجلات IANA تقول الشيء ذاته بنبرة أخرى: المعالجة القابلة للتوقع تعني تجنّب الخطوات المفاجئة، لا ضمان وصول قرارات الخبراء في عدد أيام محدد سلفاً (RFC 8720, §3.1). اقرأ الحكمين جنباً إلى جنب، فيظهر تباين ظاهري: الطرف صاحب المظلمة موقوت، والطرف صاحب القلم لم يُعطَ أي رقم. أما كون الصياغة متعمدة فليس مما يُثبت هنا.

يبدأ السلّم من حيث وقع الرفض. يوجّه RFC 8126 الطعن في قرار تسجيل إلى IESG ثم إلى IAB، ويطبّق على النزاعات التي تشمل فرق خبراء إجراء النزاع في RFC 2026 §6.5.1 (RFC 8126, §10). وهذا الإجراء المُدرج يمر برؤساء مجموعات العمل، ثم مديري المناطق المسؤولين، ثم IESG بكاملها، ثم IAB، مع إلزام كل جهة بالمراجعة ومحاولة الحل، وIAB هي الفصل الأخير في الالتزام الإجرائي والجدارة التقنية (RFC 2026, §6.5.1). وعند إثبات خلل إجرائي، تعيد IESG النظر في إجراءها وترفع تقريراً إلى IETF؛ ويجوز لـ IAB إلغاء قرار IESG واستعادة الوضع السابق، أو التوصية بإجراء، لكنه لا يستطيع اتخاذ قرارات محفوظة لـ IESG (RFC 2026, §6.5.2).

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

وثمة واقعة بنيوية أخرى، وهي الجديرة بالتثبيت فوق المكتب. ينص RFC 8126 §5.2.1 حرفياً على أن «The IESG may remove any designated expert that it appointed, at its discretion»، ويصف القسم نفسه IESG وهي تعيّن خبراء سجلات IETF وتستبدلهم، عادةً بتوصية من مدير منطقة (RFC 8126, §5.2.1). والقسم 10 يوجّه الطعن إلى الجهة نفسها أولاً. لا وفّقت أي من الوثيقتين بين دور التعيين ودور الطعن، ولا فصلاً بينهما في الأحكام المراجَعة. وأول حلقة مؤسسية مسمّاة في السلسلة هي الجهة التي تعيّن الخبير: فمسار §10 يمر برؤساء مجموعات العمل ومديري المناطق المسؤولين قبل IESG بكاملها، أما من يسمع طعناً بعينه، وهل يتصرف الأشخاص أنفسهم، فليس مما يُثبت هنا.

أحكام أخرى تلطّف الحواف دون أن تغيّر الشكل. يجوز لـ IESG استثناءً تجاوز إجراءات التسجيل حالة بحالة (RFC 8126, §3.3). والتأخيرات المتكررة غير المفسّرة في مراجعة الخبير تُلزم IANA بالتصعيد إلى IESG، التي ينبغي أن تصحح الوضع أو تستبدل الخبير (RFC 8126, §5.3) — علاج موجّه إلى التأخير لا إلى القيمة المطلوبة. ومبدأ الشفافية صريح: «the recommendations by designated experts must be visible to the public to the maximum extent possible and subject to challenge or appeal» (RFC 8720, §3.3). الرؤية موعودة. وتاريخ القرار ليس كذلك.

الملف المحيط بالمستند حيّ ويتحرك. يحدّث RFC 9907، الصادر في مارس 2026، RFC 8126 ويُبطل RFC 8407، طالباً تعليمات تربط تغييرات السجل المرجعي بصيانة وحدة YANG التي تحتفظ بها IANA، مع انتماء القيم الجديدة إلى السجل لا إلى الوحدة مباشرة (RFC 9907). وسجل التصحيحات يُظهر ما جرّبته الجماعة: التصحيح التقني 6522، المرفوض في 8 أبريل 2021، كان سيتيح صراحةً لنسخ مؤرخة من Internet-Draft أن تستوفي شرط §4.6، وقد تعامل معه المدقق كاقتراح سياسة يحتاج نقاشاً وتوافقاً لا كتصحيح خطأ؛ والتصحيح التحريري 5772، المحتفظ به لتحديث الوثيقة في 3 يوليو 2019، يتعلق بإشارة في الشكر ولا شيء غير ذلك (تصحيحات RFC 8126). هذا الرفض يسجل رفض صياغة مقترحة. ولا يثبت أن أي Internet-Draft لم يُقبل قط في الممارسة تحت قواعد أي سجل، و§4.6 كما هو مكتوب لا يذكر Internet-Drafts بين الصيغ المقبولة.

ثمة نص بديل موجود وغير نافذ. نُشر draft-ietf-ianabis-rfc8126bis-05 في 2 نوفمبر 2026؛ ويقول ملخصه إنه يُبطل RFC 8126، بينما تعلّق ترويسته ذلك على الموافقة، ويصفه حاله بأنه Internet-Draft، أي عمل قيد الإنجاز (draft-ietf-ianabis-rfc8126bis-05). لذا يُقرأ RFC 8126 هنا كنص نافذ، ويُسجّل البديل شرطياً لا استخلافاً منجزاً.

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

وحدّ بحثي واحد، يُقال مرة: ثلاث محاولات بحث في صنف وثائق وظيفة التسمية في IANA فشلت عند المزوّد قبل إغلاق هذا الخط، وعقد وظيفة التسمية وميثاق Customer Standing Committee وتقرير Naming Function Review ما زالت غير مقروءة في هذه المراجعة. هذه ثغرة في بحث هذا المكتب. وليست استنتاجاً عن تلك الوثائق.

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