يوم العلم الذي غير السلطة: الحوكمة بعد الانتقال إلى TCP/IP

ملخص

• كان الانتقال في يناير 1983 جوهريًا لكن غير متساوٍ: وجدت قياسات فبراير مئات نقاط نهاية خدمة TCP، لكن النتائج اختلفت حسب الخدمة ومجموعة العناوين وتاريخ الاختبار ومسار الشبكة، ولم تصف مجموعة عالمية تتحول في منتصف الليل.
• تم ممارسة نفوذ الراعي والمشغل من خلال ربط على مستوى IMP لحركة NCP، وقرارات الاستثناء من DDN-PMO، وتفعيل المضيفين أو المنافذ؛ ازداد الاعتماد التشغيلي على سجلات SRI-NIC وتنسيق الأرقام من قبل USC/ISI دون دليل على أن الهجرة منحت أيًا من المكتبين سلطة تقديرية جديدة.
• كانت عملية الاستثناء حقيقية لكن جزئية وليست مستقلة: كان بإمكان المسؤولين تقديم طلبات، وقائمة عامة سجلت التفعيل المؤقت لـ NCP وتواريخ انتهاء الصلاحية، وحافظت مرحّلات TAC وUDEL على إمكانية وصول محدودة، لكن الأسباب المنشورة وسجلات القرار الكاملة والمراجعة خارج DDN-PMO كانت غائبة.

في 1 فبراير 1983، بعد شهر من هدف ARPANET لتحويل NCP إلى TCP/IP، حاول اختبار من ISI-VAXA الاتصال بكل عنوان من جدول مضيفين حديث لمركز معلومات الشبكة. لم تكن النتيجة شبكة منقسمة بدقة بين ماضٍ ومستقبل. كان تقريرًا بعرض ثابت مليئًا بالاتصالات المقبولة والرفض والعناوين غير القابلة للوصول والأنظمة الميتة وحقول النتائج الفارغة.

تم استخراج قائمة المضيفين من جدول NIC المؤرخ في 28 يناير. تم إجراء الاختبارات من ISI-VAXA في 1 و2 فبراير، وأعيد اختبار المدخلات الميتة وغير القابلة للوصول والمرفوضة في 3 فبراير. حاول المسح ثلاثة خدمات TCP: Telnet وFTP وSMTP. لم يفحص البرامج، ولم يختبر جميع وظائف TCP أو IP، ولم يثبت أن مضيفًا كان متاحًا باستمرار، ولم يسرد جميع أجهزة الكمبيوتر المتصلة بشبكات الكيانات. سجل ما كان يحدث عندما حاول مصدر خدمات منفذ معينة خلال فترات معينة.

المقام فيRFC 842، « من يتحدث TCP؟ »كان 328 سطر عنوان. من بين هذه، 200 تبدأ برقم الشبكة 10، مساحة عنوان ARPANET، و128 تنتمي إلى شبكات أخرى. لم يكن السطر بالضرورة جهاز كمبيوتر ماديًا، أو مؤسسة، أو مشترك DDN، أو منظمة واحدة. يمكن أن يظهر نظام مسمى في أكثر من عنوان واحد؛ يمكن أن تظهر البوابات والإدخالات التشغيلية الأخرى أيضًا في الجدول. بالمقابل، كان النظام غير المسجل أو المفصول أو المصنف أو المحذوف خارج المجموعة المقاسة.

إعادة حساب مباشر لسطور النتائج من RFC 842 ينتج المراجعة التالية. نتيجةaccepted+لـ FTP مضمنة في مقبول. يتم احتساب مؤشر ميت أو غير قابل للوصول يغطي أعمدة الخدمة في هذه الحالة لكل خدمة.

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

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

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

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

1–18 فبراير 1983: ملاحظات متغيرة ليست منحنى تبني

توضح دراسة ثانية لماذا لا يمكن تحويل الإجماليات الكلية بسهولة إلى سردية تبني منتظم.

استخدمتRFC 843جدول مضيفين NIC مؤرخًا في 3 فبراير واختبرت من ISI-VAXA في 8 و9 فبراير. ارتفعت مجموعتها من 328 إلى 329 سطرًا. كانت الأعداد الإجمالية المقبولة 187 لـ Telnet و174 لـ FTP و170 لـ SMTP، مقارنة بـ183 و170 و169 في التقرير السابق. لكن مجموعتي الشبكة 10 وغير الشبكة 10 تحركتا في اتجاهين متعاكسين.

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

بعد عشرة أيام، طرحRFC 844سؤالًا مختلفًا. اختار 187 مدخلاً قبلت Telnet في RFC 843 وحاول الوصول إليها من مركز طرفي على شبكة الفئة C 192.1.2 في BBN. تطلب النجاح أكثر من خدمة Telnet تقبل على طول المسار السابق: كان على الحزم والردود أن تعمل عبر توجيه البوابة وعنونة الفئة C وسلوك ICMP ذي الصلة.

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

لا يمكن للمجموع 127 من 187 دعم تأكيد بسيط بأن الشبكات الخارجية كانت متأخرة عن ARPANET. كان لدى مجموعة غير الفئة A أعلى معدل ملاحظ، 30 من 32. لا يثبت الاختبار أيضًا أن كل مدخل غير ناجح يفتقر إلى دعم الفئة C أو ICMP؛ بقيت التوفرية المؤقتة وظروف المسار غير محسومة.

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

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

نوفمبر 1981: الخطة صُممت لإنهاء الوساطة

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

حددتRFC 801، التي نُشرت في نوفمبر 1981، 1 يناير 1983 كهدف للتحويل الكامل لـ ARPANET من NCP إلى IP وTCP. طلبت من كل منظمة مضيفة البدء في تنفيذ IP/TCP قبل 1 يناير 1982 وتحمّلت نفس المسؤولية المحلية لـ Telnet ونقل الملفات والبريد. كان على المضيفين الجدد لـ ARPANET البدء باستخدام TCP/IP بدلاً من الدخول عبر NCP.

تكشف معالم الخطة عن تصميمها الفعلي. كانت المضيفات القادرة على TCP فقط موجودة بالفعل. كان من المتوقع أن تقوم خدمات الترحيل بالربط بين المضيفين غير المتوافقين. كان من المقرر أن يبدأ التحويل النهائي من NCP فقط في يناير 1982؛ ومعظم المضيفين يجب أن يكونوا قادرين على TCP بحلول يوليو؛ والتحويل النهائي يجب أن يكتمل في نوفمبر. عندها فقط سيجلب يناير 1983 خدمة كاملة قائمة على TCP وإزالة NCP ونهاية الدعم العادي للمرحّل.

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

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

وضعت RFC 801 نموذجًا لسبب عدم جاذبية التعايش المطول. لا يمكن للمحطات الطرفية NCP فقط وTCP فقط التواصل مباشرة، لذا كان على المضيفات الوسيطة ثنائية البروتوكول التوسط في Telnet وFTP والبريد. تضمن Telnet حسابًا وسيطًا واتصالًا ثانيًا. يمكن أن يتطلب FTP نقل ملف على تخزين المرحّل، ثم نقله مرة أخرى. تطلب البريد منطق نقل وعنونة مع مراعاة البروتوكول. أضاف كل مرحّل جهازًا آخر يجب أن يكون متاحًا وخدمة أخرى تتطلب سعة وتحكم وصول وتوثيق ودعم.

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

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

أكتوبر–ديسمبر 1982: الامتثال دخل عبر IMP

في 1 أكتوبر 1982، من الظهر حتى الساعة 4 مساءً بتوقيت شرق الولايات المتحدة، أجرت ARPANET تجربة TCP فقط. خلال هذه الساعات الأربع، طُلب من معالجات رسائل الواجهة رفض رسائل المضيفين باستخدام الارتباط 0، الارتباط المرتبط بحركة مضيف-مضيف NCP. أعاد IMP حالة من النوع 7، الفرعي 3 تشير إلى أن الاتصال بالوجهة « ممنوع إداريًا ».

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

نقطة التطبيق مهمة. لم يكن مركز معلومات SRI هو من أزال اسمًا، ولا USC/ISI من رفض رقمًا. قامت IMP بالرفض تحت تعليمات إدارة الشبكة، مع مركز عمليات الشبكة والقيادة المرتبطة بـ DCA المسؤولة عن بيئة التشغيل. صُممت الحالة المرتجعة لجعل طبيعة الرفض الإدارية مرئية للمضيف المرسل.

ذكّر العدد 16 المسؤولين باختبار 1 أكتوبر وطلب من الكيانات الإبلاغ عن ملاحظاتهم إلى Jon Postel ومركز العمليات ومركز المعلومات. كما حث المواقع على تنفيذ SMTP وعنونة الإنترنت بأربع بايت بحلول يناير. هنا، جمع التنسيق عدة وظائف: أنشأت شبكة التبديل حالة الاختبار؛ لاحظ المنفذون ومسؤولو المضيفين الأعطال؛ تلقت ISI التقارير الفنية؛ راقب مركز العمليات العمليات؛ ووزع مركز المعلومات التعليمات وجمع معلومات التنفيذ.

تبع تجربة الأربع ساعات تكرارات أطول. أعلنالعدد 17عن فترات TCP فقط مدتها 24 ساعة في 15 نوفمبر و13 و14 ديسمبر. سيتم استخدام نفس طريقة الرفض على مستوى IMP. حذر الإشعار صراحة من أن هذه هي الآلية المخطط لها بعد هدف 1 يناير.

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

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

ومع ذلك، كان النفوذ محدودًا. كان ينطبق مباشرة على حركة NCP المقدمة عبر IMP لـ ARPANET. لم يصل إلى شبكة محلية مستقلة تدير NCP داخليًا، أو شبكة خارجية لم تنضم إلى إنترنت ARPA، أو كل عنوان غير الشبكة 10 المدرج لاحقًا في RFC 842. يمكن أن يواجه شركاء البحث الممولين من DARPA توقعات تعاقدية أو حوافز قوية للتوافق البيني، لكن هذه العلاقات لم تكن مماثلة لسيطرة DCA على عمليات ARPANET.

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

يناير 1983: كانت الاستثناءات علنية، لكن جزئيًا فقط

لم تتكون السياسة التشغيلية من موعد نهائي دون إمكانية تأجيل.

مؤرخ في 22 ديسمبر 1982،أخبار ARPANET العدد 19أشارت إلى أنه بعد 00:01 بتوقيت شرق الولايات المتحدة في 1 يناير، لن يُسمح باستخدام NCP دون استثناء محدد من مكتب إدارة برنامج DDN. أعطى اسمًا لطلب الاستثناء—reclama—وحدد كيفية تقديمه.

قبل يناير، يمكن أن يسافر الطلب عبر بريد الشبكة إلى عناوين DDN-PMO، مع نسخ إلى مركز المعلومات. بعد الموعد النهائي، يمكن للمسؤول غير القادر على استخدام الشبكة إرسال الطلب عبر البريد العادي إلى مقر DCA. كان هذا المسار دون اتصال مهمًا من الناحية التشغيلية: لم تفترض السياسة أن الشخص الذي يسعى لاستعادة الوصول إلى NCP سيظل يمتلك وصولاً وظيفيًا للشبكة.

كان على مقدم الطلب تقديم مبرر مفصل وجدول زمني للتحويل ومصدر تطبيق TCP/IP المخطط إذا كان معروفًا وقائمة بالمضيفين الذين يتطلب العمل البيني معهم. تم توفير أسماء جهات اتصال من DDN-PMO لمزيد من المعلومات. كانت هذه عملية طلب موثقة بسلطة اتخاذ قرار محددة ومتطلبات معلوماتية محددة.

العدد 20، الذي وُزع في 13 يناير، نشر بعد ذلك جدولاً لعناوين NCP المفعلة وتواريخ التحويل المخطط لها. يعطي العد المباشر 44 سطر عنوان أو منفذ. لم تكن هذه 44 منظمة مستقلة. العديد من المؤسسات لديها عدة عناوين مضيف مادية أو منطقية؛ تم تسمية سطرين كمنافذ اختبار؛ آخر حدد بوابة S1. سطر واحد كان تاريخ التحويل غير معروف. تراوحت التواريخ المؤرخة من 16 يناير إلى 1 مايو، على الرغم من أن 25 تم تعيينها في 1 فبراير.

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

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

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

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

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

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

يناير–فبراير 1983: حافظت TAC وUDEL على الفجوة حية

لم تقم الهجرة بإلغاء كل الوساطة في 1 يناير. ركزتها في مرافق محددة ومؤقتة.

أعلن العدد 20 أن وحدات تحكم الوصول الطرفي ARPANET ستستمر في دعم NCP خلال شهر يناير. يمكن لمستخدم طرفي الاتصال عبر TAC وإدخال أمر إضافي للوصول إلى مضيف NCP. في 1 فبراير، كان من المقرر أن تصبح TAC حصرية لـ TCP/IP.

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

قدمت جامعة ديلاوير جسرًا حقيقيًا آخر. وافقت UDEL على تشغيل مرحّل لنقل البريد بين مستخدمي TCP وNCP. كان مرسل TCP الذي يتجه إلى وجهة NCP يستخدم نموذج UDEL-RELAY يحتوي على حساب المستلم واسم مضيف NCP. كان مرسل NCP الذي يتجه إلى مستقبل TCP يستخدم UDEL-TCP. يمكن للمرحّل أيضًا إجراء معاملة داخل نفس البروتوكول عندما يكون الوضع الحالي للوجهة غير مؤكد.

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

تكشف هذه التسهيلات عن النسيج الفعلي للتحويل. لم يكن الامتثال والدعم متعارضين. يمكن للمشغل رفض حركة NCP العادية مع الحفاظ على بعض عناوين NCP وتوسيع دعم TAC وترتيب مرحّل بريد. قلل التوافق المؤقت من الاضطرابات دون التخلي عن الموعد النهائي.

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

هذا الاعتماد لم يجعل مركز المعلومات مصدر كل قرار. منح DDN-PMO استثناءات NCP. طبق مشغلو الشبكة التفعيل في بيئة التبديل. أدارت UDEL مرحّل البريد. قدم مشغلو TAC توافق الأطراف. وزع مركز المعلومات النشرة والجدول. سيطرت كل مؤسسة على رابط مختلف.

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

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

دخلت السجلات المسار التشغيلي دون أن تصبح سلطة فريدة

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

كانت طبقة جدول المضيفين سابقة لتحويل يناير.RFC 810، التي نُشرت في مارس 1982، استبدلت تنسيق الجدول القديم الموجه لـ ARPANET بتنسيق مصمم للربط الشبكي لوزارة الدفاع. وصف التنسيق الجديد الشبكات والبوابات والمضيفين وعناوين الإنترنت وأنظمة التشغيل والقدرات البروتوكولية. يمكن للسطر التمييز بين TCP/Telnet وNCP/Telnet أو تسجيل ما إذا كان SMTP متاحًا.

يمكن تنزيل الجدول تحت اسمHOSTS.TXTمن SRI-NIC أو الحصول عليه عبر خادم أسماء المضيفين. النسخ المحلية قللت الاعتماد على استعلام مباشر لكل اتصال، لكنها خلقت مشكلة اتساق مألوفة: نسخة قديمة يمكن أن تحتفظ بعنوان مفقود أو ادعاء بروتوكول قديم. زاد التحويل من تكرار أهمية هذه الاختلافات لأن المستخدمين والتطبيقات احتاجوا إلى معرفة ليس فقط اسم وعنوان، ولكن أيضًا بيئة الاتصال التي تدعمها الوجهة.

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

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

وصفتRFC 811خادم أسماء المضيفين لمركز المعلومات كخدمة يمكن الوصول إليها عبر NCP وTCP تُشغل في SRI لحساب DCA. يمكن للبرامج طلب سجل بالاسم أو بالعنوان أو استرداد الجدول بأكمله. حدد البروتوكول الردود المحتملة لاسم أو عنوان غير موجود أو أمر غير قانوني أو فشل نظام مؤقت.

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

ظهرت بوابة إدارية أكثر مباشرة في الإشعارات التشغيلية المحيطة بانفصال ARPANET/MILNET المخطط له. العدد 18، المؤرخ في 17 ديسمبر 1982، أشار إلى أن التسجيل الدقيق للمضيفين ومنافذ IMP كان ضروريًا لتجنب رفض الخدمة للمستخدم الخطأ أثناء الانفصال. تم توجيه BBN لتعطيل المنافذ غير المستخدمة وتفعيلها فقط بعد موافقة DDN-PMO. كان يجب تنسيق المضيفين الجدد وتغييرات المنافذ مسبقًا.

العدد 21 راجع الإجراء بعد ذلك. تم إرسال طلبات الموافقة على مضيف جديد أو تفعيل منفذ أو تغيير مضيف على منفذ نشط إلى صندوق بريد في SRI-NIC. تضمنت المعلومات المطلوبة اسم المضيف وعنوانه وموقعه وعتاده ونظام تشغيله وراعيه وبروتوكولاته وجهات اتصال الوصلة التقنية.

هنا، كانت دقة البيانات والتفعيل التشغيلي مرتبطين مباشرة. لكن السبب المذكور في العدد 18 كان انفصال الشبكة وإدارة المنافذ، وليس فقط تحويل NCP/TCP. كانت سلطة اتخاذ القرار هي DDN-PMO؛ تحكمت BBN في حالة المنافذ تحت التعليمات؛ استلم مركز المعلومات وحافظ على المعلومات ووزعها. التعامل مع الثلاثة على أنهم « السجل » سيخفي أين كانت السلطة الفعلية.

شكلت الأرقام المخصصة طبقة منفصلة أخرى.RFC 820، التي نُشرت في يناير 1983، سجلت القيم المستخدمة لأرقام الشبكة وأرقام البروتوكول والمنافذ والمقابس وحقول التنفيذ الأخرى. وجهت المتقدمين إلى Jon Postel في USC/ISI وأشارت إلى أن التخصيصات تمت في إطار اتفاق بين مكتب تقنيات معالجة المعلومات في DARPA وDDN-PMO.

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

التمييز بين هذه الآليات هو المركز السببي للقصة:

• جعل الرفض عبر IMP NCP غير قابل للاستخدام على الشبكة المُدارة، إلا حيث تم تفعيله.
• قرر DDN-PMO الاستثناءات المؤقتة لـ NCP ووافق على تفعيل المضيفين أو المنافذ.
• نفذت منظمات المضيفين وشغلت برامج البروتوكول الخاصة بها.
• سجل مركز المعلومات ووزع الأسماء والعناوين والقدرات وجهات الاتصال والإشعارات.
• نسقت USC/ISI الأرقام المخصصة للبروتوكولات والشبكات.
• حدد مشغلو البوابات والمرحّلات ما إذا كانت حركة المرور يمكنها عبور حدود تقنية معينة.
• اعتمد المشغلون الخارجيون TCP/IP في إطار اتفاقيات تمويل أو تعاون بحثي أو قواعد مشتريات أو حوافز توافق بيني لم تكن جميعها أوامر من DCA.

زادت الهجرة الاعتماد على طول هذه السلسلة. لم تدمج السلسلة في مكتب واحد.

1972–1985: الحدود المؤسسية تحولت تحت الشبكة

حتى التسلسل الزمني الأساسي يحذر من وصف سلطة مركزية مستمرة.

يؤرخالتسلسل الزمني الرسمي لـ DARPAتغيير اسم ARPA إلى وكالة مشاريع الأبحاث المتقدمة الدفاعية في عام 1972، وليس 1973. بقيت DARPA الراعي البحثي وراء الأعمال الرئيسية على البروتوكولات والتنفيذ، مع نفوذ كبير على متعاقديها وشركائها الممولين.

تاريخ تولي DCA المسؤولية التشغيلية عن ARPANET أقل وضوحًا. يشيردليل أرشيف SRI ARC/NICلعام 2011 إلى أن التشغيل نُقل إلى DCA في عام 1973. منشور معاصر لـ DCA يعطي تاريخًا رسميًا لاحقًا:كتيب معلومات ARPANETلعام 1978 التابع للوكالة يشير إلى أن مسؤولية الإدارة نُقلت في 1 يوليو 1975.

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

في يناير 1983، كان يجب فصل خمس مجموعات سكانية على الأقل.

كانت مجموعة الشبكة 10 لـ ARPANET هي الموضوع المباشر لخطة NCP/TCP لـ RFC 801 واختبارات TCP فقط على مستوى IMP. كان للسيطرة التشغيلية لـ DCA وقرارات الاستثناء من DDN-PMO أقوى تأثيرها هناك.

ينتمي MILNET ومشتركو DDN الآخرون إلى بيئة دفاع أوسع لا تزال قيد التجميع والتمييز. لم تكن التزاماتهم البروتوكولية قابلة للاختزال إلى كل سطر من خطة ARPANET. أشار تقرير المجلس القومي للبحوث لعام 1985 المعاد إنتاجه تحت اسمRFC 942إلى أن العمود الفقري لـ MILNET لم يطلب TCP نفسه، على الرغم من أن المشتركين كانوا مطالبين عمومًا باستخدامه.

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

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

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

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

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

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

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

الاعتماد الخارجي: حيث انتهى الأمر وبدأ التوافق

اعتمد النجاح الأوسع لـ TCP/IP على امتداده إلى ما وراء السكان الذين يمكن لـ DCA إدارتهم.

وصفت RFC 801 إنترنت ARPA يربط ARPANET بشبكات راديو حزم وساتلية ومحلية وغيرها. تضمنت RFC 842 وRFC 843 عناوين خارج الشبكة 10. أظهرت RFC 844 أن مسار اختبار غير الفئة A يمكنه الوصول إلى العديد من المدخلات بنجاح. تظهر هذه المصادر بيئة ربط شبكي تعبر الحدود التقنية والمؤسسية في وقت مبكر من عام 1983.

لا يثبتون نظامًا قانونيًا أو إداريًا واحدًا عبر هذه البيئة.

بالنسبة لمضيف الشبكة 10، كان رفض NCP بواسطة IMP حقيقة تشغيلية فورية. بالنسبة لشبكة مُدارة بشكل منفصل، قد تكون العوامل الحاسمة هي الوصول إلى تطبيق TCP، أو علاقة بوابة، أو عقد بحث، أو الرغبة في الوصول إلى خدمات ARPANET، أو العدد المتزايد من المراسلين المتوافقين. يمكن لشبكة استخدام TCP/IP داخليًا وخارجيًا دون قبول سلطة DDN-PMO على كل مضيف أو منفذ محلي.

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

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

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

التحويل الأبطأ كان ممكنًا، لكنه لم يكن مجانيًا

تسمح ترتيبات TAC وUDEL الفعلية بنمذجة بديل ممكن تاريخيًا دون تقنيات لاحقة في عام 1983.

افترض أن DCA احتفظت بـ NCP كخدمة ARPANET عادية بعد يناير وسمحت لمنظمات المضيفين بالهجرة طواعية. كان من الممكن أن تظل TACs ثنائية البروتوكول متاحة. كان بإمكان UDEL أو مضيفين آخرين مواصلة نقل البريد. يمكن لحسابات مرحّل Telnet وFTP الربط بين المستخدمين ومضيفي الخدمة غير المتوافقين. يمكن للمواقع تنزيل نسخ مؤرخة منHOSTS.TXTواستخدام حقول القدرة البروتوكولية لاختيار مسارات مباشرة أو مرحّلة.

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

كان الثمن سيكون خدمة انتقالية دائمة.

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

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

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

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

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

اختار التحويل الفعلي تخصيصًا مختلفًا للتكاليف. بقيت الوساطة المؤقتة متاحة، لكن تواريخ انتهائها أجبرت منظمات المضيفين على استيعاب عمل التنفيذ. استخدمت DCA وDDN-PMO السيطرة على خدمة الشبكة لجعل هذا التخصيص ذا مصداقية. استمرت الشبكات الخارجية، خارج هذه السيطرة، في اعتماد TCP/IP وفق جدولها الخاص.

كيف ربما بدا التنسيق الأكثر مسؤولية في عام 1983

لم يتطلب تحويل أكثر قابلية للقراءة أنظمة مصادقة حديثة أو تكرارًا عالميًا آليًا أو افتراضات حول موارد حوسبة وفيرة.

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

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

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

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

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

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

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

يقترح ملف التحويل أن هذا التمييز كان سيكون مفيدًا. RFC 842 يمكن أن تظهر أن عنوانًا قبل خدمة لكن ليس لماذا. العدد 20 يمكن أن يظهر أن عنوانًا احتفظ بـ NCP لكن ليس السبب الكامل. مركز المعلومات يمكنه نشر ادعاء بروتوكول لكن لا يمكنه ضمان التشغيل الملاحظ. DDN-PMO يمكنه الموافقة على منفذ، لكن الموافقة لا يمكنها إصلاح تنفيذ معطل. تسجيل أفضل لم يكن لينهار هذه الحالات؛ كان سيبقيها منفصلة.

السلطة التي تغيرت كانت محدودة بالشبكة

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

جاءت قوة التحويل من هيكل مؤسسي محدد. مولت DARPA البحث وأثرت على المتعاقدين. أدارت DCA ARPANET رسميًا منذ منتصف السبعينيات. حدد DDN-PMO سياسة التشغيل وقرر استثناءات NCP ووافق على المضيفين أو المنافذ. طبق IMPs ومشغلو الشبكات تعطيل البروتوكول. تحكمت منظمات المضيفين في التنفيذ على أجهزتهم. سجل مركز المعلومات ووزع المعلومات التشغيلية. نسقت USC/ISI الأرقام المخصصة. حافظ مشغلو TAC والمرحلات على إمكانية الوصول المؤقت.

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

كان النفوذ الممارس في مكان آخر. جعل رفض NCP على مستوى IMP سلطة الراعي والمشغل ملموسة. جعلت التفعيلات الفردية وتواريخ انتهاء الصلاحية سلطة DDN-PMO التقديرية ذات نتيجة للعناوين على الشبكة 10 المعنية. ربطت الموافقة على المضيفين والمنافذ البيانات الإدارية بتفعيل الشبكة أثناء انفصال ARPANET/MILNET. أظهرت مشاكل توزيع جدول المضيفين اللاحقة لمركز المعلومات اعتمادًا على خدمة معلومات مشتركة، وليس رفضًا سياسيًا. حافظ تنسيق الأرقام المخصصة على التفرد، لكن الملف الذي تم فحصه لا يوفر أي رفض أو استئناف متعلق بالهجرة.

خارج المجموعة المُدارة، استبدلت حوافز التوافق الأمر المباشر. اعتمد المشغلون الخارجيون TCP/IP لأن التوافق البيني مع مجتمع متزايد كان مفيدًا، أو لأن الرعاة أو برامج المشتريات دعموه، أو لأن التطبيقات أصبحت متاحة. اعتمادهم التقني على معرفات مشتركة لم يجعل شبكاتهم ملكًا لـ DCA أو DARPA أو SRI أو ISI.

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

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

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