الخلاصة

  • يعالج AFPUB-2026-ASN-001-DRAFT02 سؤالًا واحدًا مشروعًا داخل وظيفة الدفتر: هل يثبت طالب إنشاء AS-SET جديد سيطرته على رقم النظام المستقل الذي جعله جذر الاسم؟ إذا كان الجواب قابلًا للتحقق محليًا، يستطيع سجل AFRINIC قبول المدخل أو رفضه وفق قاعدة حتمية بدل أسبقية حجز تسمية بشرية مسطحة.
  • لا تتجاوز هذه القاعدة بوابة السجل. فهي لا تثبت صحة أعضاء AS-SET، ولا تفوض أصل مسار تشفيريًا، ولا تقرر سياسة المرشحات، ولا تنشئ ملكية على ASN أو على واقع BGP، ولا تمنح AFRINIC حق معاقبة شبكة أو سحب واقعها التشغيلي. التوافق أو المجلس أو الموظفون أو اتفاقية RSA لا يحوّلون أمين الدفتر إلى صاحب سيادة.
  • يحافظ المقترح على الأسماء المسطحة القائمة، ويطلب استثناءات حالةً بحالة، ومنها استعادة اسم حُذف خطأً. الاستمرارية القائمة وصف لواقع يجب ألا يكسره السجل؛ أما الاستعادة فهي عملية سجل جديدة يجب أن تبقى مقيدة بإثبات الهوية السابقة. لا يجوز أن تتحول كلمة «استثناء» إلى إنفاذ تقديري أو امتياز يمنحه موظف.
  • عند حد الأدلة في 9 أغسطس/آب 2026، لا توجد حجة موثقة بأن المقترح اعتُمد أو نُفذ. فالفهرس الرسمي يضعه «قيد النقاش»، بينما تعرض صفحة المقترح «الدعوة الأخيرة» وتذكر عرضه في AF37 يوم 24 يونيو/حزيران. والمواد الرسمية تثبت فقط ما قاله أصحابها وما فعلوه؛ لا تنشئ بمجرد النشر سلطة ولا واقعًا تشغيليًا.

سجلٌ للواقع، لا مصنعٌ له

تبدأ المسألة من فصل بسيط لا يحتمل المساومة: الطريق موجود لأن الشبكات تشغله، لا لأن قاعدة بيانات سمحت به. وقرار المشغّل في اختيار جيرانه ومصادر بياناته ومرشحاته موجود لأنه قرار محلي تتحمل الشبكة أثره، لا لأنه تفويض صادر من AFRINIC. أما سجل التوجيه فيؤدي وظيفة أضيق: يعرض كائنات يستطيع الآخرون الرجوع إليها في التنسيق، ويحتفظ ببيانات صيانة وتفويض تساعد على معرفة مَن يملك حق تعديل سجل بعينه.

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

التمييز حاسم في قضية AS-SET. يستطيع AFRINIC أن يقول: «لن أضيف إلى قاعدة بياناتي اسمًا جديدًا بهذه البنية إلا إذا اجتاز طالب الإنشاء اختبارًا محددًا». لا يستطيع أن يستنتج من ذلك أن الاسم هو الحقيقة الوحيدة في قواعد أخرى، أو أن محتواه صحيح، أو أن المشغلين ملزمون باستخدامه، أو أن شبكة لا تتبع الاختيار نفسه أصبحت مخالفة في الواقع. سلطة القبول داخل دفتر خاص لا تساوي سلطة على الإنترنت.

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

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

ما الفجوة التي يحاول المقترح إغلاقها؟

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

ينسب نص المقترح إلى صاحبه، James Bensley من Inter.link GmbH، القول إن أسماء AS-SET ليست فريدة عبر سجلات RIR الخمسة، وإن المحللات التي تجمع المصادر قد تعيد توسعًا خاطئًا أو فارغًا. هذا قول منسوب إلى المقترح، لا إحصاءً مستقلًا لحجم الحوادث. وتعرض مادة MANRS مثالًا تشغيليًا على اختلاف المصادقة بين اسم مسطح واسم متجذر في ASN، كما تعرض تصادمًا لاسم AS-AMAZON بين RADB وRIPE. المثال يثبت إمكان الآلية، ولا يثبت قصدًا خبيثًا أو معدلًا عامًا أو خسارة محددة في AFRINIC.

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

تعليمات AFRINIC المنشورة لاستخدام IRR عبر MyAFRINIC تصف أسماء مسطحة تبدأ بـAS-، وتصف المصادقة ببيانات المشرف. كما أن إعلان AFRINIC المؤرخ في 14 أبريل/نيسان 2020 قال إن تكامل MyAFRINIC مع IRR دخل الإنتاج، مع مصادقة للمشرف عبر كلمة مرور أو آلية PGP اختيارية. هذه المواد تثبت سير عمل منشورًا في سجل AFRINIC؛ ولا تثبت أن كل منفذ برمجي طبق دائمًا القاعدة نفسها، ولا أن نجاح بيانات المشرف يمنح الاسم فرادة عالمية.

المقترح ينقل الإثبات إلى بنية الاسم نفسها. بدل اسم من نمط AS-CUSTOMERS وحده، يبدأ الاسم الجديد بمكوّن AS يتبعه رقم نظام مستقل، ثم نقطتان رأسيتان، ثم مكوّن AS-SET يبدأ بـAS-. ويجوز أن تضاف طبقات أعمق تكون أرقام أنظمة مستقلة أو أسماء AS-SET. مثال بنيوي مثل AS64500:AS-CUSTOMERS لا يشير إلى مشغل بعينه؛ وظيفته أن يوضح سؤال الخادم: هل يملك الطالب بيانات التفويض المرتبطة بالكائن AS64500؟

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

سلسلة تفويض، لا هرم حكم

يحدد RFC 2622 نحو أسماء المجموعات الهرمية، ويجعل مشرف الأصل صاحب تفويض إنشاء الفرع المباشر تحته. عند الجذر القائم على ASN، يكون مشرف كائن ASN هو صاحب التفويض للابن الأول. وإذا أنشئ AS-SET أب، يصبح مشرف ذلك الأب صاحب التفويض للفرع الأعمق. هذا توزيع لصلاحيات تحديث أسماء في بنية بيانات، لا دستورًا لحكم الشبكات.

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

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

كما أن RFC 2622 لا يمنح AFRINIC ولاية مستمدة من المعيار. الوثيقة تحدد نحو RPSL ودلالاته، وتقول إن إجراءات التسجيل خارج نطاقها. أي إن المعيار يعطي المشاركين لغة مشتركة، بينما يظل قرار AFRINIC في رفض اسم مسطح جديد قرارًا بشأن ما تقبله قاعدة AFRINIC. لا تستطيع AFRINIC استعارة مكانة RFC لتوسيع قرارها إلى قواعد أخرى أو إلى سلوك الشبكات.

المسار المؤسسي داخل AFRINIC يستطيع أن يعدّل قواعد خدمة AFRINIC إذا استوفى إجراءاته، والموظفون يستطيعون بناء تحقق في WHOIS وMyAFRINIC إذا تقرر ذلك. لكن حتى اعتماد النص داخليًا لا ينشئ سيادة. أقصى ما يفعله هو تحويل شرط قبول في دفتر AFRINIC من اقتراح إلى قاعدة خدمة. وقوة القاعدة العملية لا تأتي من عبارة «اعتمدت»، بل من تنفيذ متطابق يستطيع المشغل اختباره في كل منفذ.

ما تحميه المصادقة الضيقة

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

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

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

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

ما لا تخلقه القاعدة

لا تصدق الهرمية أعضاء AS-SET. يستطيع اسم متجذر في ASN ومُنشأ بتفويض صحيح أن يحتوي لاحقًا على أعضاء غير دقيقين أو قدامى أو مكررين. المقترح لا يغيّر قواعد صحة الأعضاء ولا ينشئ مراقبة دائمة لمحتواهم. لذلك فإن الشكل الهرمي إشارة إلى سلطة الإنشاء، لا ختم جودة للمجموعة كلها.

ولا تحل الهرمية اختيار المصدر. قواعد AFRINIC لا تقيد RADB أو أي سجل طرف ثالث، ولا تجبر محللًا على سؤال AFRINIC أولًا، ولا تمنع قاعدة أخرى من السماح باسم يشبهه. يحمل سجل PeeringDB الخاص بـGoogle رقم ASN 15169 ومرجعًا مؤهلًا بالمصدر هو RADB::AS-GOOGLE. هذا يثبت أن المستهلك يستطيع حمل اسم الكائن ومصدره معًا. ويظل عليه أن يحافظ على ذلك المؤهل وأن يحدد ترتيب مصادره وأسلوب التعامل مع التوسع.

ولا تغيّر القاعدة RPKI أو ROA. يميز مصدر NRS المدرج في الحزمة بين IRR، الذي يقدم سياق سياسة التوجيه، وRPKI، الذي يقدم تفويضًا تشفيريًا لأصل المسار. كما عدّ تقييم موظفي AFRINIC نظام RPKI من الأنظمة التي لا تحتاج إلى تغيير من أجل المقترح. إثبات حق إنشاء اسم مجموعة لا يصبح تفويضًا تشفيريًا لإعلان بادئة.

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

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

حالة المقترح: لا واقع من وسم صفحة

قُدمت DRAFT01 في 15 مايو/أيار 2026 بحسب تاريخ المراجعات في صفحة DRAFT02. وقُدمت DRAFT02 في 8 يونيو/حزيران بعد ملاحظات القائمة البريدية، وأضافت نص الاستثناء الصريح. الفاصل بين التاريخين 24 يومًا. نشر موظفو AFRINIC تقييم أثر مؤرخًا في 15 يونيو/حزيران، بعد سبعة أيام. وتقول صفحة المقترح إنه عُرض في AF37 يوم 24 يونيو/حزيران، بعد تسعة أيام أخرى.

هذه التواريخ تثبت تسلسلًا من أقوال وأفعال منسوبة: مؤلف قدّم نصًا؛ موظفون نشروا تقييمًا؛ صفحة رسمية قالت إن عرضًا وقع. لا يثبت أي منها وحده اعتمادًا أو نفاذًا. التقييم الفني ليس تشريعًا، والعرض ليس تصويتًا سياديًا، ووصف «الدعوة الأخيرة» ليس كودًا عاملًا.

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

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

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

الكود العامل هو الاختبار، لا خاتم المؤسسة

حدد تقييم الموظفين ستة أنظمة. قال إن WHOIS وواجهة IRR في MyAFRINIC يحتاجان إلى تغييرات مباشرة. وقال إن RDAP سيعكس بيانات WHOIS. وعدّ NetSuite وNMRP وRPKI بلا تغيير. هذه خريطة أثر منسوبة إلى الموظفين، لا مراجعة هندسية مستقلة ولا ضمانًا بأن التنفيذ وقع.

إذا نُفذ المقترح، يجب أن يتطابق التحقق في الخادم والنماذج والواجهات. فالواجهة التي ترفض اسمًا مسطحًا بينما تقبله API لا تغلق الفجوة. والخادم الذي يتحقق من وجود النقطتين الرأسيتين ولا يتحقق من تفويض ASN ينتج مظهرًا هرميًا بلا إثبات سيطرة. والفرع الأعمق الذي لا يطلب تفويض الأب المباشر يكسر سلسلة RFC 2622.

لا توجد في الحزمة مصفوفة اختبارات منشورة تغطي حالة الأحرف، والجذور غير المخولة، والفروع المتداخلة، ومسارات WHOIS وMyAFRINIC وواجهات البرمجة، والحذف والاستعادة. غيابها لا يثبت فشل التنفيذ؛ يثبت فقط أن النجاح لم يُبرهن عند حد الأدلة. وعلى المراقب أن يحافظ على هذا الفرق بدل ملئه بثقة مؤسسية.

ربط الموظفون الجدولة بـMyAFRINIC v2، التي كانت متوقعة في تقييمهم بتاريخ 15 نوفمبر/تشرين الثاني 2026، وقالوا إن عمل السياسة سيحصل على الأولوية بعدها. كان ذلك الموعد يبعد 98 يومًا عن 9 أغسطس/آب. لكنه توقع وارد في تقييم يونيو، لا التزام نشر مثبت. ولم يعرض التقييم ساعات جهد أو ميزانية أو نتائج اختبار.

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

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

الاستمرارية القديمة: الدفتر ملزم بوصف ما لا يملكه

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

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

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

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

والحد العقائدي هنا واضح: AFRINIC لا «تسمح» للشبكة بأن تبقى حقيقية. هي تختار ألا تكسر سجلًا قائمًا بقاعدة جديدة. عدم التعدي على الاستمرارية ليس كرمًا مؤسسيًا؛ هو واجب أمين الدفتر تجاه واقع يعتمد عليه الآخرون.

الاستعادة ليست مملكة للاستثناء

تطلب DRAFT02 أن تسمح AFRINIC باستثناءات تُنظر حالةً بحالة، وتقدم استعادة AS-SET مسطح حُذف خطأً مثالًا. وقد حذر الموظفون من أن يصبح الاستدعاء أو الاستعادة ثغرة تشغيلية تقوض الهدف، واقترحوا توثيق سبب الاستثناء. هذه هي نقطة الاحتكاك بين قاعدة حتمية وبين تدخل بشري غير محدد.

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

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

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

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

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

المقارنات الإقليمية لا تنقل ولاية

يسجل APNIC رسميًا أن prop-151 وصل إلى التوافق في 2 مارس/آذار 2023، وإلى التأييد في 21 أبريل/نيسان، ونُشر بوصفه سياسة منفذة في 20 يوليو/تموز. وتثبت سجلات RIPE الرسمية أن تقييد إنشاء AS-SET مسطح جديد نُشر في الإصدار 1.105 بتاريخ 13 ديسمبر/كانون الأول 2022. الحالتان تثبتان أن قاعدة مستقبلية مع استمرارية للقديم قابلة للتنفيذ.

لكن التنفيذ في APNIC وRIPE لا يصنع إجماعًا عالميًا ولا يمنح AFRINIC سلطة مستعارة. لكل سجل كوده ومساراته، وكل مستهلك يحتفظ بقراره. قيمة المقارنة هندسية: لقد نفذ آخرون نمطًا مشابهًا. ولا يجوز تحويلها إلى شرعية سياسية: «الآخرون فعلوا، إذن يجب أن تطيع الشبكات هنا».

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

أما ARIN، فرفض مجلسها الاستشاري في 30 أبريل/نيسان 2025 مقترح ARIN-prop-342 باعتباره خارج نطاق سياسة موارد الأرقام، وأحال الموضوع إلى مسار اقتراح الخدمة. وبعد مشاورة من 23 أبريل/نيسان إلى 23 مايو/أيار، أُغلق الملف في 30 مايو/أيار بإضافة الميزة إلى قائمة عمل مستقبلية لتحديد الأولوية. هذا يثبت مسارًا إداريًا ووضعًا مستقبليًا، لا نشرًا إنتاجيًا.

الحصيلة الدقيقة عند موعد الأدلة: حالتان مقارنتان موثقتان للتنفيذ، APNIC وRIPE؛ ممارسة هرمية موثقة في مواد LACNIC من دون إثبات كامل لكل مسارات الرفض؛ وميزة مستقبلية غير مثبتة النشر في ARIN. لهذا فإن قول صاحب المقترح إن الاستيلاء لن يعود ممكنًا عبر السجلات الخمسة أوسع مما تسمح به المواد المختومة.

أقوى اعتراض: أصلح المستهلك قبل أن تغيّر الاسم

يقول أقوى دفاع عن الوضع القائم إن المصدر المؤهل وسياسة الحل الصريحة يستطيعان تقليل الالتباس من جانب المستهلك. مرجع مثل RADB::AS-GOOGLE يحمل المصدر والاسم معًا. وإذا حافظت الأدوات على المؤهل، ومنعت السقوط الصامت إلى مصدر آخر، وأعلنت ترتيب البحث، فقد لا تحتاج إلى ادعاء فرادة عالمية للاسم.

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

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

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

الكلفة والمصلحة من دون أرقام مختلقة

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

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

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

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

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

ما نعرفه وما لا نعرفه

نعرف النص المقترح، وهوية صاحبه، وتواريخ النسختين، وتاريخ تقييم الموظفين والعرض. نعرف الصيغة، وتفويض جذر ASN، وسلطة مشرف الأب على الفرع الأعمق بحسب RFC 2622. نعرف حماية الأسماء القائمة، ووجوب الاستثناء حالةً بحالة، وتحذير الموظفين من الثغرة.

ونعرف خريطة الأنظمة التي نشرها الموظفون: تغييران مباشران، ونظام يعكس WHOIS، وثلاثة أنظمة بلا تغيير. نعرف أن APNIC وRIPE وثقا تنفيذًا، وأن ARIN أعلنت عملًا مستقبليًا، وأن أدلة LACNIC لا تكفي وحدها لإثبات كل منفذ. ونعرف أن المصادر المؤهلة ممكنة في السجلات التشغيلية.

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

ولا نعرف هل كل منفذ سيطبق التحقق نفسه، ولا هل موعد MyAFRINIC v2 سيتحقق، ولا متى تنفذ ARIN ميزتها، ولا هل كل واجهات LACNIC ترفض الاسم المسطح. هذه ليست ثغرات بل حدود معرفة يجب أن تبقى معلنة. المؤسسة لا تملأ المجهول بسلطتها، والمقال لا يملؤه بالتخمين.

الحكم: قاعدة دفتر نافعة فقط داخل حدها

AFPUB-2026-ASN-001-DRAFT02 صالح بوصفه قاعدة تنسيق دنيا محتملة: اسم جديد متجذر في ASN، وإثبات سيطرة على الجذر، وسلسلة تفويض للأب، ورفض حتمي للطلب غير المخول. هذه العناصر تحمي فرادة السجل ودقته وقابلية الاعتماد عليه في التنسيق.

لكن الصلاحية تنتهي عند هذا الحد. لا يستطيع المقترح أن يخلق ملكية، ولا أن يمنح AFRINIC حكم سياسة على الشبكات، ولا أن يبرر عقابًا، ولا أن يربط سجلًا بمصادرة أو revocation، ولا أن يجعل قرار الموظف حقيقة تشغيلية. السجل يصف مَن أثبت السيطرة في قاعدة AFRINIC؛ ولا يخلق واقع التوجيه أو سلطة عليه.

التوافق لا يزيد الحد. والمجلس لا يزيده. والموظفون لا يزيدونه. وRSA لا تزيده. هذه الأدوات قد تنظم خدمة أو تسجل موقفًا أو ترتب عقدًا، لكنها لا تصنع سيادة. إذا بقيت AFRINIC أمين دفتر وطبقت اختبارًا رقيقًا، كان المقترح تحسينًا تقنيًا. وإذا استُخدم الاسم الهرمي ذريعة لتوسيع التحكم إلى سلوك المشغل أو لمعاقبة غير الممتثل، انقلبت القاعدة من تنسيق إلى تعدٍّ.

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

وهكذا يكون الحكم شرطيا في الوقائع وحاسما في العقيدة: لا دليل على النفاذ عند 9 أغسطس/آب 2026. وإذا اعتُمد النص ونُفذ متطابقًا، يمكنه تحسين سلطة إنشاء الأسماء الجديدة داخل دفتر AFRINIC. لكنه لن يجعل AFRINIC مالكةً للاسم أو الطريق، ولن يحكم الشبكات، ولن يغني عن المصدر أو تدقيق الأعضاء أو RPKI. الدفتر الصادق مهم؛ والدفتر الذي يتوهم أنه يخلق العالم الذي يسجله يصبح خطرًا على صدقه.

المصادر