RFC 1366 واللحظة التي أصبح فيها التخصيص الإقليمي ممكنًا

ملخص

• اقترح RFC 1366 توزيع التسجيل مع الحفاظ على التنسيق المركزي لـ IANA وسجل الإنترنت، وتجميع مساحة الفئة C جغرافياً لمواجهة مسافة الخدمة، وندرة الفئات، وتجميع التوجيه.
• يظهر النص والتنفيذ الأوروبي المبكر إقليمية حقيقية، لكنهما لا يثبتان حصرية إقليمية دائمة، أو ملكية، أو موافقة على مستوى المشغلين، أو آلية كاملة للاستبدال والاستئناف.

المشكلة المقاسة جمعت بين عبء إداري وضغط معماري. في لمحة حزيران/يونيو 1992 حسب الفئات، أحصى RFC 1366 49 فتحة من أرقام الشبكة من الفئة A مخصصة من أصل 126، و7,354 فتحة من الفئة B من أصل 16,383، و44,014 فتحة من الفئة C من أصل 2,097,151. كان من الصعب خدمة الشبكات متوسطة الحجم بكفاءة: أرقام الفئة B كانت نادرة، لكن تخصيص العديد من شبكات الفئة C غير المرتبطة زاد من جداول التوجيه. استجاب RFC 1366 بتوزيع التسجيل، وحجز كتل من الفئة C منظمة جغرافياً، وتخصيص مجموعات متجاورة بناءً على توقعات 24 شهراً، مع الإبقاء على IANA وسجل الإنترنت المركزي كجهات تنسيق وافتراضية.

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

تم التنفيذ الأوروبي من خلال إجراءات مؤرخة وغير متزامنة. تحدد وثائق RIPE بداية تشغيل مركز التنسيق الشبكي (NCC) في 1 نيسان/أبريل 1992، وتصفه بأنه يعمل كسجل مفوض اعتباراً من 1 أيار/مايو، وتذكر طلب سجل الإنترنت المركزي في تموز/يوليو لمعالجة الطلبات الأوروبية، وتؤرخ النقل التلقائي لهذه الطلبات في 1 آب/أغسطس. في نهاية ربع آذار/مارس 1993، أفاد RIPE 87 عن تخصيص 10,348 رقم شبكة وسجل جزئي لـ 143 طلباً.

وصف RIPE 92 لاحقاً أكثر من 10,000 رقم شبكة خلال السنة الأولى من التشغيل، بينما ادعى RIPE 99 بأثر رجعي أكثر من 14,000 لتلك السنة نفسها، وأفاد بشكل منفصل، عند نقطة مراقبته في 25 تشرين الأول/أكتوبر 1993 بعد 18 شهراً، عن أكثر من 60 سجل مزود خدمة و21 سجل دولة غير مزود. لا تقدم التقارير مجموعة بيانات ثابتة مشتركة للتوفيق بين هذه الإجماليات.

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

تشرين الأول/أكتوبر 1992: طابور مركزي في مواجهة شبكة متوسعة

RFC 1366، "إرشادات لإدارة مساحة عناوين IP"كُتب بواسطة Elise Gerich من Merit Computer Network ونُشر في تشرين الأول/أكتوبر 1992. أعلن عن وضعه دون غموض: قدمت المذكرة معلومات لمجتمع الإنترنت ولم تحدد معيار إنترنت. لم يجعل هذا التصنيف الوثيقة تافهة. كان بإمكان RFC إعلامي تنسيق المؤسسات، وتحديد خطة عملية، والتأثير على الإجراءات التشغيلية. ما لم يستطع توفيره بمجرد نشره هو إجراء الموافقة المرتبط بالمعيار، ناهيك عن تصويت جميع الشبكات التي ستعتمد لاحقاً على نظام التخصيص.

الأسماء المؤسسية المحيطة بالوثيقة تتطلب الحذر. يوسع ملخص RFC 1366 اختصار FEPG إلى "Federal Engineering Task Force"؛ وتستخدم شكره "Federal Engineering Planning Group"؛ وRFC 1367تسميه "FNC Engineering and Planning Group". المصدر غير متسق، لذا لا ينبغي التعامل مع أي توسيع واحد بوصفه قانونياً دون غموض. FEPG هو الاختصار الأكثر أماناً.

أشار RFC 1366 إلى أن FEPG راجع الاقتراح نيابة عن Federal Networking Council، إلى جانب الرؤساء المشاركين لمجموعة التخطيط الهندسي الدولية (IEPG) وRIPE. ذكرت وجود إجماع عام بين هذه المجموعات لدعم التوصيات. نسب الشكر لأعضاء FEPG وIEPG مساهمات جوهرية، وأرجع المفاهيم إلى جلسة Birds of a Feather في IETF حول العنونة في كامبريدج (ماساتشوستس) في تموز/يوليو 1992، وذكر Jon Postel وYakov Rekhter كمراجعين ومساهمين.

هذا إطار إنشاء جوهري، لكن كل جهة لعبت دوراً محدوداً. Gerich كانت المؤلفة. FEPG والمجلس الفيدرالي كانا جزءاً من هيكل شبكي فيدرالي. IEPG جلبت مشاركة دولية في الهندسة والتخطيط. جلسة BoF في IETF قدمت مكاناً لتطوير واختبار الأفكار التقنية. RIPE كانت كمجموعة تنسيق وجهة تنفيذ ناشئة. IANA وسجل الإنترنت المركزي كانا الجهتين المفترض أن تحجزا المساحة، وتحافظا على الجذر، وتعترفا بالسجلات، وتنسقا التفويض. مقدمو الشبكات، والمشتركون، والسجلات المحلية، والطالبون كانوا مجموعات معنية، غير قابلة للتبديل مع مجموعات الصياغة والمراجعة.

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

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

العنونة حسب الفئات جعلت عبء العمل أكثر من مجرد مشكلة خدمة. أفاد الجدول 1 في RFC 1366 بلقطة حزيران/يونيو 1992 بوحدات فتحات أرقام الشبكة. بالنسبة للفئة A، 49 فتحة مخصصة مقسومة على 126 تعطي 38.8889%، وهو ما يُقرب إلى 39% بدلاً من 38% المطبوعة في RFC. بالنسبة للفئة B، 7,354 مقسومة على 16,383 تعطي 44.8892%، وهو ما يتوافق مع 45% المطبوعة. بالنسبة للفئة C، 44,014 مقسومة على 2,097,151 تعطي 2.0988%، وهو ما يتوافق مع 2% المطبوعة.

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

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

كان للقلق بشأن التوجيه نقطة مرجعية تجريبية.RFC 1338، المنشورة في حزيران/يونيو 1992، أعادت إنتاج سلسلة شهرية من المسارات المُعلَن عنها من Merit تضم 1,525 مساراً في نيسان/أبريل 1990 و4,775 في شباط/فبراير 1992. الفرق هو 4,775 ناقص 1,525، أي 3,250 مساراً إضافياً. مقارنة بمرجع نيسان/أبريل 1990، كان هذا يمثل زيادة بنسبة 213.1% على مدى 22 شهراً.

حدد RFC 1338 المصدر بـ Merit وربط الأرقام بمعلومات التوجيه الخالية من العيوب الموضحة في قاعدة بيانات توجيه NSFNET. لم يكن تعداداً لجميع أجهزة التوجيه. وحدة المراقبة كانت مساراً مُعلَناً في هذه السلسلة الشهرية عند تاريخيّ المراقبة المذكورين، وليس طلب عنوان، أو طالباً، أو مشتركاً، أو مشغلاً، أو شبكة مخصصة، أو مستخدم إنترنت. كانت قيمته في إظهار الضغط عند نقطة نظر توجيه مهمة، وليس توفير مقام عالمي.

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

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

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

كان RFC 1174 قد وزع الخدمة بالفعل دون إلغاء المركز

ظهرت الهندسة السابقة قبل عامين فيRFC 1174، التي كتبها Vinton Cerf ونُشرت في آب/أغسطس 1990. كانت هذه الوثيقة إعلامية أيضاً وقدمت صراحةً توصيات بدلاً من معيار إنترنت. سجلت وجهة النظر الرسمية لمجلس أنشطة الإنترنت (IAB) في توصيات إلى مجلس الشبكات الفيدرالي (FNC).

اقترحت RFC 1174 الحفاظ على وظائف IANA وسجل الإنترنت المركزية. في ذلك الوقت، كانت وظيفة IANA تُدار من قبل معهد علوم المعلومات (ISI) بجامعة جنوب كاليفورنيا، بينما كان مركز معلومات شبكة DDN (DDN NIC) في SRI International يؤدي وظيفة سجل الإنترنت لأرقام الشبكة والأنظمة المستقلة. سيبقى سجل الإنترنت السجل الأساسي والخيار الافتراضي عندما لا يتم تحديد سلطة تسجيل مفوضة.

سيتم التوزيع من خلال التفويض الخاضع للرقابة. يمكن لسجل الإنترنت تخصيص كتل من أرقام الشبكة والأنظمة المستقلة لمنظمات توافق عليها اللجنة التنسيقية لأبحاث الشبكات عبر القارات (CCIRN) ومنحها سلطة التخصيص الفرعي. كان على السجلات المرشحة مقابلة IANA وسجل الإنترنت، ومراجعة المتطلبات التشغيلية، وتوثيق نمط التشغيل الموزع المقترح.

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

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

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

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

أفعال التوصية تظل مهمة. اقترحت RFC 1174 وأوصت وتوقعت. لم تنشر قائمة مدققة تظهر أن كل تفويض أو عملية تكرار أو فصل سياسات قد تم تنفيذه. كان مسار موافقتها عبر CCIRN وIANA وسجل الإنترنت قناة مؤسسية محددة، وليس مقاماً لجميع المشغلين الذين قد يتأثرون.

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

هذا الهيكل يقاوم تبسيطين متعارضين. أحدهما يختزل الإقليمية إلى لامركزية تجميلية لأن المركز بقي. ومع ذلك، كان من المفترض أن تمارس السجلات الإقليمية مسؤولية حقيقية عن الخدمة والتخصيص الفرعي. الآخر يتعامل مع الكتل الجغرافية على أنها نقل للسيادة أو الملكية. وصفت RFC 1366 الحجز والتخصيص والتوزيع والتسجيل والتفويض. لم تعرّف نقلاً للملكية.

الكلمة الصعبة كانت "واحد"

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

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

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

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

معايير اختيار بدون ملف اختيار قابل للتكرار

حاولت RFC 1366 تحديد ما يجب أن يكون عليه السجل الإقليمي بدلاً من مجرد تسمية منظمة متاحة. اقترحت خمسة معايير. معاً، تظهر أن المؤلف فهم التفويض كقرار مؤسسي، وليس مجرد تكوين تقني. كما تكشف كم من إجراء القرار بقي غير مُصاغ.

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

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

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

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

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

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

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

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

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

الكتل الجغرافية كانت تقنية تخصيص، لا إقليم

اقترحت RFC 1366 تقسيم جزء من نطاق الفئة C إلى ثماني كتل متساوية. بعد ملاحظة أن البادئتين 192 و193 كانتا مستخدمتين بالفعل بينما بقي جزء كبير من 194 إلى 223 غير مخصص، حجزت 208 إلى 223 حتى إشعار آخر ونظمت 192 إلى 207 في أزواج من /8.

وصفت RFC كل زوج بأنه يحتوي على 131,072 "عنواناً"، لكن الوحدة التشغيلية للفئة كانت 131,072 فتحة من أرقام الشبكة من الفئة C. كل فتحة تقابل اسمياً نطاقاً بحجم /24 من 256 قيمة IPv4 خام. بضرب 131,072 في 256 نحصل على 33,554,432 قيمة خام في كل زوج من /8. مقارنة بمقام الفئة C لـ RFC 1366 البالغ 2,097,151 فتحة، تمثل 131,072 فتحة حوالي 6.25%، وهو ما يتوافق مع وصف الوثيقة التقريبي بحوالي 6%.

التسميات كانت مؤقتة وواسعة: 192-193 كان متعدد الإقليمي؛ 194-195 كان أوروبا؛ 196-197 كان "أخرى"؛ 198-199 كان أمريكا الشمالية؛ 200-201 كان أمريكا الوسطى والجنوبية؛ 202-203 كان المحيط الهادئ؛ و204-207 قدمت كتلتين إضافيتين "أخرى". لم تكن هذه خريطة ناضجة لخمس مؤسسات دائمة. احتوت على أربع مناطق جغرافية مسماة، ونطاق متعدد الإقليمي، وثلاثة نطاقات مرنة.

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

كان على التخصيصات داخل الكتلة استخدام قوى اثنين متجاورة بناءً على الحاجة المتوقعة للمشترك على مدى 24 شهراً. التسلسل العادي كان شبكة من الفئة C لأقل من 256 عنواناً، وشبكتين متجاورتين لأقل من 512، وأربع لأقل من 1,024، وثمان لأقل من 2,048، وست عشرة لأقل من 4,096. كانت هذه قواعد تحجيم للتخصيص ضمن الخطة، وليست إحصائيات للطلبات أو الطالبين أو القرارات الناجحة.

يجب التمييز بين العناوين الخام والمضيفين القابلين للاستخدام. /24 يحتوي على 256 قيمة IPv4 خام. وفقاً للمعالجة التقليدية في ذلك الوقت، لم تكن معرفات المضيف الكل-أصفار والكل-واحد متاحة للمضيفين العاديين، مما يترك 254 معرف مضيف قابل للاستخدام. ستة عشر /24 متجاورة تحتوي على 4,096 قيمة خام لكن 4,064 مضيفاً قابلاً للاستخدام تقليدياً. توقف مثال الفئة C الطبيعي المتجاور في RFC 1366 عند ست عشرة شبكة ووجه الاحتياجات فوق 4,096 عنواناً فريداً نحو اعتبار محتمل للفئة B.

النموذج الأوروبي الذي نُشر لاحقاً باسمRIPE 83عرض مثالاً يصل إلى 32 شبكة من الفئة C. في اتفاقية المضيفين لهذا النموذج، 32 مضروباً في 254 يعطي 8,128 مضيفاً قابلاً للاستخدام؛ نفس 32 /24 تحتوي على 8,192 قيمة خام. المقارنة تظهر استمرارية في التحجيم بقوى اثنين، لكن ليس عتبة عليا متطابقة. نموذج مستخدم في الممارسة الإقليمية يمكن أن يوسع خيار الفئة C المعروض إلى ما بعد مثال RFC 1366 العادي المكون من ست عشرة شبكة.

الفئة B بقيت خاضعة للسيطرة المركزية في RFC 1366. الشروط الأساسية للوثيقة تطلبت أكثر من 32 شبكة فرعية وأكثر من 4,096 مضيفاً، مع اعتبار كل حالة على حدة عندما تكون كتل الفئة C غير عملية. يمكن للسجل الإقليمي المساعدة في التقييم، لكن IANA وسجل الإنترنت احتفظا بمسؤولية الفئة. لذا كانت الإقليمية جوهرية دون أن تكون شاملة لجميع فئات العناوين.

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

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

وضع RFC 1367 تواريخ مقترحة بجانب الخطة

التقويم المصاحب لـ RFC 1366،RFC 1367، كتبه Claudio Topolcic ونُشر في تشرين الأول/أكتوبر 1992. كان إعلامياً أيضاً. كانت لغته واضحة بشكل غير معتاد بشأن الوضع: اقترح تقويماً، ودعا هذا التقويم مسودة، وقال إنه تم تجميعه من جلسة العنونة في IETF في تموز/يوليو 1992 ومناقشات مع عدد - وليس كل - الأطراف المختصة والمهتمة، بما في ذلك IANA وسجل الإنترنت.

الموعد الأول، 31 تشرين الأول/أكتوبر 1992، طالب بأن تكون المعايير الأولية للسجل الإقليمي جاهزة وأن تقبل IANA طلبات السجلات المحتملة. تم وصف أرقام الفئة A بأنها شبه مستحيلة الحصول عليها. أرقام الفئة B ستتطلب مبرراً معقولاً، مع تفضيل كتل الفئة C حيثما أمكن. تخصيص الفئة C سيتبع خطة العنونة، مع عمل سجل الإنترنت المركزي حيث لا يوجد سجل إقليمي معين.

تم التخطيط لمراجعة وإعادة ضبط محتملة في 14 شباط/فبراير 1993. بحلول 15 نيسان/أبريل، كان على سجل الإنترنت البدء في تخصيص جميع الشبكات وفقاً لخطة العنونة في كتل من الفئة C بحجم مناسب، بينما ستصبح أرقام الفئة B أكثر صعوبة في الحصول عليها. آخر تاريخ مذكور، 6 حزيران/يونيو 1993، كان التوفر المخطط لآلية تجميع عناوين على الإنترنت.

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

يجب إثبات التنفيذ في مكان آخر، وظيفة بوظيفة. كتلة مفوضة، طلب محول، تحديث قاعدة بيانات، إعادة تخصيص محلي، تفويض DNS عكسي، تقييم طلب، ومسار مجمع كانت أفعالاً مختلفة. لم تحدث بالضرورة في نفس التاريخ ولا تثبت تحقيق كل معلم مخطط.

أوروبا كانت تنفذ بقطع

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

RIPE 65، الإصدار 0.6 المؤرخ 1 تموز/يوليو 1992، قال إن مركز تنسيق شبكة RIPE (RIPE NCC) كان يعمل كسجل مفوض لأرقام الشبكات IP الأوروبية منذ 1 أيار/مايو. وصف سياسة تخصيص لمقدمي الخدمات ومراكز معلومات الشبكة ومراكز عمليات الشبكة بدلاً من المنظمات الفردية مباشرة. هؤلاء الوسطاء سيعيدون تخصيص الأرقام للطالبين.

المراجعة بأثر رجعي في تشرين الأول/أكتوبر 1993 تقدم تسلسلاً مختلفاً.RIPE 99، المؤرخ 25 تشرين الأول/أكتوبر 1993 والمستعرض لأول 18 شهراً من NCC، وضع بدايته التشغيلية في 1 نيسان/أبريل 1992. قال إن سجل الإنترنت المركزي طلب من RIPE NCC في تموز/يوليو 1992 معالجة جميع الطلبات من المنظمات الأوروبية. بعد التشاور مع رئيس RIPE ومجموعات العمل المعنية، قبل NCC رغم الإجراءات غير المكتملة. اعتباراً من 1 آب/أغسطس، كانت الطلبات الأوروبية التي تصل مركزياً عبر البريد الإلكتروني أو البريد تُحول إلى RIPE NCC.

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

RIPE 72، الإصدار 0.7 المؤرخ 16 تشرين الأول/أكتوبر 1992، وصف مرة أخرى نشاط السجل المفوض اعتباراً من 1 أيار/مايو. وثق نقل كتل كاملة من الفئة C إلى مقدمي الخدمات ومراكز الشبكة المحلية، وإعادة المساحة غير المستخدمة عند الطلب، والإبلاغ عن إعادة التخصيص في قاعدة بيانات RIPE، وتجنب التخزين، وتخصيصات متجاورة بقوى اثنين محاذية لحدود بت مناسبة. الإجراء توقع التجميع لكنه قال أيضاً إن التجميع الفائق (supernetting) لم يتم تبنيه رسمياً بعد. التوافق الإجرائي كان حاضراً قبل النشر العالمي للتوجيه.

التسلسل الهرمي المرئي للطالب كان موثقاً في RIPE 83، المؤرخ 23 آذار/مارس 1993. قال النموذج إن العملية التي كانت مركزية في أوروبا قد استُبدلت بنظام موزع: السجل العالمي يفوض كتل إلى RIPE NCC، وRIPE NCC يفوض إلى السجلات المحلية، ويتوجه الطالبون عادةً إلى مزود الخدمة الخاص بهم أو إلى سجل محلي غير مزود. طلبات الفئة B تبدأ محلياً لكنها تُحول إلى RIPE NCC للمراجعة إذا رأى السجل المحلي أنها مبررة.

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

RIPE 83 تجعل وحدة التخصيص مرئية أيضاً. استخدمت أمثلته حسابات مضيفين قابلين للاستخدام: 254، 508، 1,016، 2,032، 4,064، و8,128 لشبكة واحدة، اثنتين، أربع، ثمان، ست عشرة، و32 شبكة من الفئة C. هذا التسلسل يختلف عن إجماليات العناوين الخام من 256 إلى 8,192. أكبر مثال معروض للفئة C تجاوز الحد الطبيعي لـ RFC 1366 البالغ ست عشرة شبكة، مما يظهر أن التنفيذ المبكر يمكن أن يحافظ على الآلية الثنائية مع تعديل نطاقها العملي.

أكثر دليل على عبء العمل تفصيلاً يأتي منRIPE 87، التقرير الربعي لآذار/مارس 1993. للربع المعني، قال إن 143 طلباً قد استُلمت. قنوات الاستلام المطبوعة كانت 51 من سجل الإنترنت العالمي، و86 أُرسلت مباشرة إلى RIPE NCC، و5 استُلمت من السجلات المحلية. هذه الإجماليات الفرعية مجموعها 142، وليس 143. لا يقدم التقرير فئة رابعة أو تصحيحاً يوفق الفرق البالغ طلباً واحداً.

RIPE 87 استبعد صراحةً التوجيهات البسيطة حيث تم توجيه الطالب ببساطة إلى السجل المحلي المناسب دون استلام RIPE NCC طلباً. لذا فإن إجمالي 143 ليس مقاماً لجميع طلبات العناوين الأوروبية، أو جميع طلبات السجلات المحلية، أو جميع المنظمات التي تبحث عن أرقام خلال الربع. كما أن 86 تقديماً مباشراً لا تثبت تجاوزاً ناجحاً للنظام الإقليمي: كانت طلبات استُلمت من قبل المركز الإقليمي، وليس دليلاً على أن الطالب تجنب الإدارة الإقليمية أو حصل على خدمة مركزية.

نفس السجل الربعي أبلغ عن مقاييس وقت الاستجابة لمجموعة طلباته المسجلة. قال إن 82.5% من الطلبات تلقت رداً - وليس مجرد إشعار استلام - في نفس يوم استلامها، وأن 97.9% تلقت رداً في غضون سبعة أيام تقويمية من استلام RIPE NCC لها. أبلغ بشكل منفصل عن متوسط فترات زمنية تقل قليلاً عن خمسة أيام لتخصيص فئة C عولج من قبل NCC وأقل قليلاً عن عشرة أيام لتخصيص فئة B.

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

قال RIPE 87 أيضاً إن أكثر من 90% من حالات الفئة B التي تم تقييمها اعتُبرت غير مبررة وفقاً للمعايير المتفق عليها مع السجل العالمي وIANA. لم يحدد عدد حالات الفئة B التي تم تقييمها، لذا لا يمكن استعادة البسط من النسبة المئوية. في الإجراء الموصوف، تم تحويل هذه الحالات إلى السجل المحلي المناسب لتخصيص فئة C. "غير مبررة" وفقاً لمعايير الفئة B لا ينبغي تحويلها إلى سجل كامل للرفض أو الضرر للطالب أو الاستئنافات أو الفشل النهائي في الحصول على مساحة عناوين.

قسم مساحة العناوين في RIPE 87 أبلغ أنه خلال الربع، خصص RIPE NCC 14 رقم شبكة من الفئة B، وفوض 32 كتلة من أرقام الشبكة من الفئة C، وحجز 15 كتلة من الفئة C. قال إن السجلات الأوروبية خصصت 3,235 شبكة من الفئة C خلال الربع، ليصل الإجمالي المعلن إلى 10,348 رقم شبكة مخصص في نهاية ربع آذار/مارس 1993. هذه وحدات إدارية على مستويات مختلفة: أرقام شبكة فردية من الفئة B، وكتل مفوضة أو محجوزة، وأرقام شبكة من الفئة C مخصصة. لا شيء منها هو عدد الطالبين.

يسجل RIPE 87 أيضاً فعلاً تنفيذياً منفصلاً في نظام الأسماء. قال إن منطقة DNS العكسية 193.in-addr.arpa قد فُوّضت إلى RIPE NCC في 16 آذار/مارس 1993، وتم تفويض 11 نطاقاً فرعياً لاحقاً إلى سجلات محلية تحمل كتل فئة C عند نقطة مراقبة التقرير. الوحدة كانت نطاقات DNS العكسية تحت هذه المنطقة، وليس طلبات العناوين أو قرارات التخصيص. هذا يظهر تسلسلاً هرمياً تشغيلياً يتجاوز سجل التخصيص دون إثبات تحقيق معلم التوجيه في RFC 1367.

الإجماليات السنوية والأثرية تتطلب معالجة منفصلة.RIPE 92، المنشور في 3 أيلول/سبتمبر 1993 تحت عنوان "السنة الأولى لـ RIPE NCC"، وصف سنة التشغيل من نيسان/أبريل 1992 إلى آذار/مارس 1993 وقال إن أكثر من 10,000 رقم شبكة IP قد تم تخصيصها. الوحدة كانت أرقام الشبكة المخصصة عبر نظام السجل الأوروبي، وليس قيم IPv4 الخام أو المنظمات الطالبة. بيانه المقرب متوافق إلى حد كبير مع 10,348 في RIPE 87 في نهاية ربع آذار/مارس.

صرحت RIPE 99 لاحقاً أنه بعد سنة من التشغيل، نظام السجل الأوروبي خصص أكثر من 14,000 رقم شبكة IP. هذا أيضاً ادعاء بأثر رجعي عن السنة الأولى، لكنه أعلى مادياً من 10,348 في RIPE 87 و"أكثر من 10,000" في RIPE 92. التقارير المتاحة لا تقدم مجموعة بيانات ثابتة مشتركة، أو تاريخ إغلاق، أو معالجة للإدخالات التاريخية، أو قاعدة تجميع بأثر رجعي، أو بسط دقيق كافٍ للتوفيق بين الأرقام الثلاثة. السجل الحذر يحافظ على كل مصدر وتاريخ ونافذة ووحدة بدلاً من اختلاق إجمالي مركب.

إحصائيات السجلات في RIPE 99 تشير إلى نقطة مراقبة مختلفة. في 25 تشرين الأول/أكتوبر 1993، بعد 18 شهراً من تشغيل NCC، قال إن النظام الموزع كان قائماً آنذاك مع أكثر من 60 سجل مزود خدمة و21 سجل دولة غير مزود خدمة. هذه هي السجلات المبلغ عنها كموجودة في تاريخ مراجعة تشرين الأول/أكتوبر. لا ينبغي نقلها إلى الوراء وتصنيفها كإحصائيات السنة الأولى.

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

المراجعة وثقت أيضاً الارتجال. خطة عمل NCC في أيار/مايو 1991 لم تتضمن صراحة دور سجل IP الأوروبي. وفقاً لـ RIPE 99، تم اقتراح أنشطة تتجاوز الخطة الأصلية، ونوقشت داخل RIPE، ونُفذت عند التوصل إلى نتيجة إيجابية. الطلب المركزي في تموز/يوليو 1992 سرّع وظيفة السجل قبل أن تستقر كل إجراء. هذا دليل على التكيف من قبل هيئة تنسيق نشطة، وليس دليلاً على تفويض إقليمي كامل مسبق.

على مستوى الكتل العليا،سجل مساحة عناوين IPv4 لـ IANAالحالي، في النسخة المحدثة بتاريخ 2025-10-10، يسرد 193/8 و194/8 و195/8 تحت RIPE NCC بتواريخ 1993-05. هذه تواريخ على مستوى الشهر في سجل حالي. لا تشكل لقطة فورية لأيار/مايو 1993، أو تواريخ دقيقة للتخصيص الفرعي، أو سجلات نقل، أو ملفات طلب، أو دليل على الدافع.

السطر الحالي لـ 193/8 ذو صلة بالخريطة المنشورة. RFC 1366 كانت قد وضعت 192-193 في كتلة متعددة الإقليمي بينما حددت 194-195 لأوروبا. المعالجة اللاحقة لـ 193/8 من قبل السجل تحت RIPE NCC تظهر أن خطة تشرين الأول/أكتوبر 1992 لم تُطبق كتقسيم ثابت. لا يمكنها وحدها شرح عملية القرار أو تأريخ كل تفويض من مستوى أدنى.

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

ما يثبته الملف التشغيلي

أقوى دليل على التنفيذ يتعلق بالخدمة الموزعة. أوصت RFC 1174 بالتفويض؛ قدمت RFC 1366 المؤهلات الإقليمية وخطة الكتل الجغرافية؛ وثقت RIPE 65 وRIPE 72 إجراءات تخصيص عاملة؛ وجهت RIPE 83 الطالبين عبر تسلسل هرمي عالمي-إقليمي-محلي؛ وقاست RIPE 87 جزءاً من عبء العمل الناتج. هذا أكثر من مجرد طموح مؤسسي.

اللجوء المركزي له ملف دليل مختلف. وعدت RFC 1366 بأن سجل الإنترنت سيبقى مستعداً لخدمة المشتركين إذا لزم الأمر. قالت RIPE 99 إن الطلبات الأوروبية التي تصل مركزياً كانت تُحول إلى RIPE NCC اعتباراً من 1 آب/أغسطس 1992. سجلت RIPE 87 لاحقاً 51 طلباً ربعياً وردت من السجل العالمي، لكن هذه كانت محولة ضمن العملية الإقليمية. الملف المدروس يفتقر إلى سجل كامل للطالبين الذين خدموا مباشرة من قبل المركز، أو تم توجيههم إقليمياً، أو حصلوا على استثناء، أو سُمح لهم بالإصرار على المعالجة المركزية.

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

تلقت الكفاءة التشغيلية بعض الدعم بأثر رجعي. نشرت RIPE 87 أوقات الاستجابة ومقاييس عبء العمل، بينما أثنت RIPE 99 على الدقة والسرعة. هذه الملاحظات تتعلق بالأداء المبكر لـ RIPE NCC. لم تضع RFC 1366 معايير رقمية قبل الاختيار، لذا لا يمكن للنجاح اللاحق إعادة بناء تقييم المرشحين أو تحديد البدائل التي تم النظر فيها.

الاعتراف أقل قابلية للتكرار. كان لـ RIPE دور تنسيق راسخ، ومنظمات مشاركة، وإطار رسمي عبر RARE. هذه الحقائق تتوافق مع تفضيل RFC 1366 لوضع خارج وظيفة السجل. ينقص قائمة كاملة لمقدمي الخدمة والمشتركين الإقليميين، وسجل بالتأييد والاعتراضات، وطلبات المرشحين المنافسين، واختبار موثق لـ "معترف به على نطاق واسع".

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

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

الفاعلون، السلطة، واللجوء المفقود

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

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

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

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

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

الملف المدروس هنا لا يحتوي على أرشيفات كاملة لصياغة المؤلف، أو مراسلات FEPG أو IEPG، أو نص جلسة BoF حول العنونة في IETF، أو مقارنة سجلات المرشحين، أو مقام موافقة إقليمية، أو سجل اعتراضات، أو ملف استئناف تعيين. لا ينبغي تحويل هذا الفجوة إلى معارضة خفية. كما يمنع أن يصبح الصمت إجماعاً مقاساً.

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

البديل القابل للتنفيذ في ذلك الوقت لم يكن سجلًا مشتركًا حديثًا

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

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

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

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

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

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

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

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

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

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

بديل ثانٍ أكثر طموحًا كان سيسمح بتكرار حقيقي متعدد الكتّاب: عدة سجلات تحدث الحالة المرجعية مع توفيق لاحق. وثائق الفترة المدروسة لا تثبت أن هذه كانت الهندسة المقصودة. كانت ستتطلب تقسيم تخصيص خالٍ من التصادم أو ترتيب معاملات قوي، وتبادل تحديثات موثقة، واكتشاف سجلات متباينة، وتعافيًا من انقسامات الشبكة، وقاعدة تحدد أي كاتب يسود. معاملة سجل مشترك حديث الصوت كخيار بدون جهد في عام 1992 سيمحو السبب التقني وراء احتفاظ RFC 1174 بالتحديثات المركزية.

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

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

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

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

اللحظة التي أصبح فيها التخصيص الإقليمي ممكنًا

جعلت RFC 1366 التخصيص الإقليمي ملموسًا من خلال ربط مشاكل لم يعد يمكن معالجتها بشكل مستقل. النمو الدولي ضغط على واجهة خدمة واحدة. اللغة والقرب الإداري فضلا التوزيع. ندرة الفئة B جعلت عادات التحجيم القديمة غير مستدامة. تخصيصات متعددة للفئة C هددت نمو التوجيه ما لم تكن الكتل متجاورة ومتوافقة مع التجميع.

وفرت RFC 1174 الهندسة الأساسية: الحفاظ على IANA وسجل الإنترنت المركزي، وتفويض وظائف التخصيص عبر منظمات معتمدة، وتوزيع نسخ من قاعدة البيانات مع مركزية التحديثات، وفصل التسجيل عن تطبيق سياسة الشبكة. أضافت RFC 1366 مؤهلات إقليمية، وخطة جغرافية للفئة C، وعتبات تحجيم، وتفضيلًا صريحًا لسجل واحد على المستوى الإقليمي. وضعت RFC 1367 تواريخ مقترحة بجانب هذه الخطة دون إثبات أن كل معلم تحقق.

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

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

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