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 بدء تشغيل مركز تنسيق الشبكة في 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، “Guidelines for Management of IP Address Space”من قبل إليز جيريك من شبكة ميريت للكمبيوتر ونُشر في أكتوبر 1992. أعلن وضعه دون غموض: قدمت المذكرة معلومات لمجتمع الإنترنت ولم تحدد معيار إنترنت. لم يجعل هذا التصنيف الوثيقة تافهة. كان بوسع RFC الإعلامي تنسيق المؤسسات، وتحديد خطة عملية، والتأثير على إجراءات التشغيل. ما لم يستطع توفيره بمجرد النشر هو إجراء الموافقة المرتبط بمعيار، ناهيك عن تصويت بين كل شبكة ستعتمد لاحقاً على نظام التخصيص.

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

قال RFC 1366 إن FEPG راجع الاقتراح نيابة عن مجلس الشبكات الفيدرالي، إلى جانب الرؤساء المشاركين لمجموعة التخطيط الهندسي الدولي وRIPE. وأبلغ عن إجماع عام بين تلك المجموعات دعماً للتوصيات. ونسب الشكر لأعضاء FEPG وIEPG على مساهمات كبيرة، وتتبع المفاهيم إلى جلسة طيور على الشجرة لـ IETF في كامبريدج، ماساتشوستس، في يوليو 1992، وسمى جون بوستل وياكوف رختر كمراجعين ومساهمين.

هذه بيئة إنشاء كبيرة، لكن كل فاعل احتل دوراً محدوداً. كان جيريك هو المؤلف. كانت 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، سلسلة شهرية للطرق المعلنة من ميريت تحتوي على 1,525 طريقاً في أبريل 1990 و4,775 في فبراير 1992. الفرق هو 4,775 ناقص 1,525، أي 3,250 طريقاً إضافياً معلناً. بالنسبة لخط أساس أبريل 1990، كانت تلك زيادة بنسبة 213.1 بالمئة على مدى 22 شهراً.

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

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

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

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

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

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

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

سيتم التوزيع من خلال تفويض مراقب. يمكن لسجل الإنترنت تخصيص كتل من أرقام الشبكات والأنظمة المستقلة لمنظمات توافق عليها اللجنة التنسيقية لشبكات البحوث العابرة للقارات ويمنحها سلطة تعيين إضافية. كان يتوقع من السجلات المرشحة أن تجتمع مع 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 جهازاً قابلاً للاستخدام تقليدياً. توقف مثال RFC 1366 العادي للفئة C المتجاورة عند ست عشرة شبكة ووجه المتطلبات فوق 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، كتبه كلاوديو توبولسيك ونُشر في أكتوبر 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 عمل كسجل مفوض لأرقام شبكات 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 بوظيفة السجل قبل أن تستقر كل الإجراءات. هذا دليل على تكيف عبر هيئة تنسيق نشطة وليس دليلاً على ولاية إقليمية شاملة مسبقة.

على مستوى الكتلة العليا، يسجلIANA IPv4 Address Space Registryالحالي، في النسخة المحدثة آخر مرة في 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 قوى العدد اثنين، وكتلاً محاذية، وطلبات متوقعة. لكن الجاهزية الإدارية وتأثير التوجيه بقيا منفصلين. لا تقيس تقارير التخصيص ما إذا كان قد تم الإعلان عن مجموع، أو قبوله عند موجه معين، أو تقسيمه بتعدد الموطن، أو إزاحته بطرق أكثر تحديداً. وصفت سلسلة ميريت ضغط التوجيه عند نقطة مراقبة محددة؛ ووصفت سجلات السجل نشاط التخصيص.

اكتسبت الكفاءة التشغيلية بعض الدعم الاستعادي. نشر 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، أو نص جلسة عنونة IETF BOF، أو مقارنة سجل مرشح، أو مقام تأييد إقليمي، أو سجل اعتراضات، أو ملف استئناف تعيين. لا ينبغي تحويل تلك الفجوة إلى معارضة خفية. وهي تمنع بالمثل أن يصبح الصمت إجماعاً مقاساً.

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

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

يبدأ عد واقعي مفيد بقبول الحاجة للتوزيع. بحلول عام 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 على جذر واحتياطي مركزي لكنه ترك الشروط العملية للمراجعة المركزية غير مؤكدة.

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