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

ملخص

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

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

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

كان المقام فيRFC 842، “Who Talks TCP?”هو 328 صف عنوان. من بينها، بدأ 200 برقم الشبكة 10، وهو فضاء عناوين ARPANET، و128 ينتمون إلى شبكات أخرى. لم يكن الصف بالضرورة حاسوباً مادياً فريداً أو مؤسسة أو مشتركاً في DDN أو منظمة. يمكن أن يظهر نظام مسمى في أكثر من عنوان؛ كما يمكن أن تظهر العبّارات والإدخالات التشغيلية الأخرى في الجدول. على العكس، كان النظام غير المسجل أو المنفصل أو المصنف أو المحذوف خارج المجموعة المقاسة.

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

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

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

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

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

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

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

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

تكشف المعالم الرئيسية للخطة عن تصميمها الفعلي. كانت المضيفات القادرة على TCP والتي تعمل بـ 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 نقل ملف إلى تخزين الترحيل ثم نقله مرة أخرى. تطلب البريد منطق توجيه وعناوين مدركة للبروتوكول. أضاف كل مرحّل جهازاً آخر يجب أن يكون متاحاً وخدمة أخرى تحتاج سعة وتحكماً في الوصول وتوثيقاً ودعماً.

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

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

أكتوبر–ديسمبر 1982: انتقل الإنفاذ إلى داخل IMP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يناير–فبراير 1983: أبقت TACs وUDEL الوصلة حية

لم يُلغِ الانتقال كل وساطة في 1 يناير. ركزها في تسهيلات محددة ومؤقتة.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

كيف كان يمكن لتنسيق أكثر خضوعاً للمساءلة أن يبدو في 1983

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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