ملخص

  • أفاد بيان مؤهلات SRI لعام 1988 بأرقام العقود وتواريخها وتمويلها والأعمال المنجزة، لكن النسخ العامة للعقود الأساسية والتعديلات وبيانات العمل لم يعثر عليها، مما ترك الالتزامات الدقيقة والعلاجات والفترات المتداخلة دون حل.
  • دعمت مشتريات وكالة اتصالات الدفاع (DCA) خدمات مركز معلومات الشبكة (NIC) ضمن تسلسل شبكة بيانات الدفاع (DDN) ووزارة الدفاع (DoD)، بينما وفرت قواعد تشغيل DDN وسياسات نطاق مجلس هندسة الإنترنت (IAB) ووكالة مشاريع البحوث المتقدمة الدفاعية (DARPA)، وتفويض IANA من قبل USC/ISI والاعتماد الخارجي جسوراً منفصلة خاصة بالخدمة لا يمكن دمجها في ولاية تعاقدية عالمية.
  • يُظهر التسليم في عام 1991 أن مزود الخدمة تغير مع استمرار نقل البيانات وقنوات الطلب والخدمات؛ وهو لا يثبت شروط المشتريات المفقودة أو واجبات الانتقال أو الملكية أو التكاليف أو العلاجات للمستخدمين الخارجيين.

رواية مقاول عن سجله الخاص

الجدول العام الأكثر تفصيلاً لأرقام عقود DDN-NIC لا يأتي من عقد موقع من وكالة اتصالات الدفاع، أو بيان عمل أو تقرير تفتيش حكومي. بل يظهر في وثيقة لشركة SRI International بتاريخ 27 أكتوبر 1988 أُعدت لفرصة مختلفة تماماً:بيان مؤهلات للعرض F04701-88-R-0043: الدعم الفني لمركز معلومات نظام تحديد المواقع العالمي. قدم مركز نظم المعلومات الشبكية (Network Information Systems Center) في SRI الوثيقة لإثبات قدرته على تطوير وتشغيل مركز معلومات GPS مدني مقترح. كان نقاشه لـ DDN-NIC بمثابة خبرة مؤسسية قدمت لدعم ذلك العرض.

هذا المصداق يغير كيفية قراءة كل مدخل في الجدول. أبلغت SRI أن العقد DCA200-83-C-0025 استمر من 1 يونيو 1983 إلى 31 ديسمبر 1985 وبتمويل قدره 3,122,367 دولاراً. وأبلغت أن العقد DCA200-84-C-0024 استمر من 15 يونيو 1984 إلى 31 يناير 1987 وبتمويل 8,128,495 دولاراً. وأدرجت العقد DCA200-87-C-0020 لفترتين سنويتين تبدأان في 1 فبراير 1987، بمبلغ 3,772,115 دولاراً للسنة الأولى و4,121,252 دولاراً للسنة الثانية. التواريخ متداخلة. ولأن النسخ العامة للعقود الأساسية والتعديلات وبيانات العمل لم يعثر عليها، لا يمكن تفسير التداخل بأمان على أنه خيار، أو حزمة عمل منفصلة، أو ترتيب جسر، أو تغيير في الهيكل التعاقدي.

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

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

جزء واحد من السلسلة المبلغ عنها له إثبات فدرالي منفصل. تسجل الخدمة الوطنية للمعلومات التقنية (NTIS) دليل بروتوكولات DDN، المجلد الأول: بروتوكولات وزارة الدفاع العسكرية القياسية لعام 1985 كتقرير فني من SRI DDN-NIC أُنتج تحت العقد DCA200-83-C-0025. يصف سجل NTIS دليلاً للمنفذين الذين يخططون لتوصيل حواسيب بشبكة بيانات الدفاع، بما في ذلك ARPANET. ويحدد أدوار DCA ومكتب إدارة برنامج DDN في توحيد البروتوكولات وإدارة التشكيل. وهذا يثبت أن رقم العقد ارتبط على الأقل بهذا الناتج الموثق. لكنه لا يكشف بقية نطاق العقد، أو هيكل الدفع، أو العلاجات، أو حقوق من لم يكونوا طرفاً فيه.

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

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

سلسلة الشراء التي يمكن إثباتها

العلاقة المؤسسية الرئيسية واضحة على المستوى العالي. وزارة الدفاع وفرت الإطار الحكومي. وأدارت DCA شبكة بيانات الدفاع وتعاقدت مع SRI لأعمال NIC. وكانت SRI International المقاول. وكان DDN-NIC مركز العمليات الذي قدمت من خلاله SRI خدمات التسجيل والمعلومات والمساعدة. شكلت مرافق DDN ومستخدمو ARPANET وMILNET الموثقون الفئة التي تظهر لها سلطة التشغيل الحكومية بأوضح صورة.

يصف دليل متحف تاريخ الحاسوب لعام 2011دليل سجلات SRI ARC/NICالأرشيف الباقي على أنه يحتوي على عروض، وبيانات عمل، وعقود، وتعديلات، ومراسلات، وتقارير تقدم شهرية، وتقارير مخرجات العقود. ويذكر أنه بحلول عام 1987 كان عمل NIC يتكون من مهام عديدة مع قادة مهام وميزانيات مخصصة. ويوصف أن التقارير الشهرية الرسمية استمرت حتى عام 1991، بينما تغطي تقارير مخرجات العقود الفترة من 1980 إلى 1990. لذا فإن دليل الأرشيف يحدد أنواع السجلات المرتبطة عادة بإدارة العقود الحكومية: أدوات مرقمة، وهياكل مهام، وميزانيات، وتقارير، وملفات تعديلات.

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

أقوى دليل على الخدمات المقدمة بالفعل يأتي من وثائق التشغيل المعاصرة. RFC 811، الذي صدر في مارس 1982، وصف خادم أسماء المضيفين كواحد من سلسلة خدمات الأسماء التي يديرها NIC التابع لـ SRI نيابة عن DCA. RFC 954، المنشور في أكتوبر 1985، حدد خادم NICNAME/WHOIS بالطريقة نفسها. سجل كتيب NTIS يربط منشوراً رئيسياً لـ DDN بأحد أرقام العقود المبلغ عنها. RFC 1032، الذي أصدرته SRI في نوفمبر 1987، ذكر أن DCA عينت NIC لتقديم خدمات سجل النطاقات لأجزاء DDN وDARPA من الإنترنت.

وبحلول فبراير 1991، كان RFC 1206 لا يزال يحدد SRI International كمشغل لـ NIC.DDN.MIL، ومستودع لـ RFCs ومسودات الإنترنت، ومزود لمساعدة مستخدمي DDN، وموقع سجل الإنترنت، ومشغل لخدمات النطاق وWHOIS.

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

تغير اسم الوكالة قرب نهاية الفترة. احتفظت DCA بهذا الاسم حتى 25 يونيو 1991، حين أعاد توجيه وزارة الدفاع 5105.19 تسميتها إلى وكالة نظم معلومات الدفاع (DISA). تستخدم الروايات المعاصرة واللاحقة أحياناً الاسمين بشكل غير دقيق عند مناقشة الانتقال، لكن التاريخ مهم. DCA هو اسم الوكالة الصحيح لعقود SRI المبلغ عنها في 1983 و1984 و1987. DISA هو الاسم الصحيح للوكالة المحددة في إشعار التسليم التشغيلي في سبتمبر 1991.

هناك فجوة مادية بين هاتين النقطتين. جدول مؤهلات SRI لعام 1988 يعطي 31 يناير 1989 كنهاية لفترة DCA200-87-C-0020 المدرجة. RFC 1206 يثبت أن SRI كانت لا تزال تشغل DDN NIC في فبراير 1991، ويصف الدليل الأرشيفي تقارير شهرية خلال ذلك العام. لم تحدد أي وثيقة عامة مراجعة الخيار، أو التمديد، أو العقد الجسري، أو التعديل، أو الترتيب الخلف الذي دعم العمل من فبراير 1989 إلى التسليم في 1991.

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

ما جعلته قواعد DCA إلزامياً

داخل بيئة DDN، ارتبطت إجراءات DDN-NIC بسلطة التشغيل الحكومية بقواعد أكثر تحديداً من وضع المقاول الخاص.

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

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

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

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

كان بإمكان الخدمة أن تكون مفيدة للعامة وإلزامية رسمياً لفئة محددة في آن واحد. الإتاحة العامة لم تجعل كل المستخدمين مستفيدين تعاقديين. والتسجيل الإلزامي لمستخدم TAC في MILNET لم يثبت التزاماً مماثلاً لموظف في شبكة جامعة أجنبية.

تظهر رقابة DCA أيضاً في تعليمات التقديم لـ RFC 1032. إذا كان تبني اسم نطاق مؤهل بالكامل سيغير اسم المضيف الرسمي لمضيف ARPANET أو MILNET، كان على مقدم الطلب الحصول على موافقة DCA مسبقاً والسماح بوقت للمعالجة. الجسر الإداري واضح: المضيف المتأثر ينتمي لبيئة تدار من DCA؛ اسمه المقترح يغير سجلاً رسمياً مستخدماً في تلك البيئة؛ NIC يعالج الطلب؛ وموافقة DCA مطلوبة.

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

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

السلطة التي وفرتها سياسة الإنترنت

لم تكن المشتريات الجسر الوحيد بين DDN-NIC والإنترنت الأوسع. يجب وزن السلطة الإيجابية التي منحتها السياسة التقنية بشروطها الخاصة.

RFC 920، الذي نشره جون بوستل وجويس رينولدز في USC/ISI في أكتوبر 1984، أعلن نفسه بيان سياسة رسمي لمجلس أنشطة الإنترنت وDARPA. وحدد متطلبات إنشاء نطاقات في ARPA-Internet ومجتمع أبحاث DARPA. احتاجت النطاقات إلى مديرين مسؤولين، وخدمة أسماء موثوقة، وتسجيل ضمن التسلسل الهرمي. أُدرج NIC كوكيل للنطاقات العليا الأولية. حُددت DARPA كمدير لـ ARPA وGOV وEDU وCOM وORG؛ وكان مكتب إدارة برنامج DDN مديراً لـ MIL.

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

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

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

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

حصل مدير النطاق المحتمل على استبيان، وقدم التفاصيل التنظيمية والتقنية المطلوبة، وأعاد النموذج المكتمل إلى HOSTMASTER في SRI. قال الدليل إن الطلب يجب أن يكون مكتملاً قبل أن تأذن NIC بإنشاء النطاق. كما وصف ترتيبات تسجيل بديلة تعالج بموجبها منظمات إدارة CSNET وUUCP الطلبات لمجتمعاتها وتمرر المعلومات ذات الصلة إلى NIC لإدراجها في قاعدة البيانات المركزية وملفات الجذر.

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

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

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

الأرقام وIANA وسجل الإنترنت

اتبعت إدارة أرقام الإنترنت مساراً مؤسسياً آخر. التمييز بين وظيفة IANA في USC/ISI ووظيفة سجل الإنترنت لدى SRI أساسي، لأن صندوق البريد نفسه للموظفين كان ليبدو بخلاف ذلك مستمداً كل سلطة من مشتريات DCA.

RFC 1020، الذي نشره موظفو SRI في نوفمبر 1987، أعلن أن Hostmaster في DDN-NIC تولى مسؤولية تعيين أرقام شبكات IP وأرقام الأنظمة المستقلة. وأقر باستمرار المساعدة من جون بوستل وجويس رينولدز في USC/ISI. كانت الوثيقة تقرير حالة رسمي يسرد المعرّفات المعينة؛ ولم تستنسخ الاتفاقية التي نقلت العمل التشغيلي.

قدم RFC 1174 الرواية السياسية المعاصرة في أغسطس 1990. وصف وظيفة IANA بأنها تؤدى في USC/ISI وذكر أن IANA لديها سلطة تقديرية لتفويض أجزاء من مسؤولية المعرّفات. بالنسبة لأرقام الشبكات والأنظمة المستقلة، قال إن المسؤولية قد أودعت لدى سجل الإنترنت الذي تديره SRI في DDN-NIC. لذا كانت SRI أكثر من مجرد متلق سلبي للنماذج. ضمن الترتيب التقني المقبول، كانت السجل الرئيسي لتلك المعرّفات.

كان ذلك التفويض جسر سلطة إيجابي. وهو يفسر لماذا قد تقدم منظمة خارج فئة مشتريات DDN مع ذلك طلب رقم إلى DDN-NIC وتعتبر النتيجة موثوقة. أراد مقدم الطلب معرّفاً فريداً عالمياً معترفاً به من قبل نظام تنسيق الإنترنت المشترك. وكانت وظيفة IANA في USC/ISI قد وضعت مسؤولية التسجيل ذات الصلة لدى SRI. واستشار مشغلون آخرون التعيينات التي يصدرها السجل وأعادوا استخدامها لتجنب التصادمات.

كان للجسر مع ذلك حواف محددة. أبقى RFC 1174 على تمييز مؤسسي بين IANA وسجل الإنترنت. أدى USC/ISI وظيفة IANA المركزية؛ وأدت SRI أعمال السجل المفوضة إليها. وأوصى IAB بأن يخصص السجل كتلاً لمنظمات إقليمية معتمدة وأن توزع سلطة التعيين الإضافية دولياً. وكان على DDN-NIC أن يبقى سجلاً افتراضياً حيث لا يوجد سجل مفوض، بينما ستشارك نسخ مجمعة من بيانات التسجيل لتحسين الوصول والتكرار.

لا يثبت RFC 1174 الأساس التعاقدي الكامل لعلاقة IANA مع DARPA أو DCA أو SRI. إن قوله بأن IANA تملك سلطة تفويض تقديرية يسجل الترتيب السياسي المعترف به من IAB. وهو ليس بديلاً عن اتفاقيات DARPA وDCA المفقودة. واجه مكتب محاسبة الحكومة الأمريكية مشكلة إثباتية مماثلة في عام 2016 عند فحص مصالح الملكية الحكومية في وظائف الإنترنت التاريخية: تعذر الحصول على عقود رئيسية من السبعينيات حتى التسعينيات، مما حال دون استنتاجات واثقة بشأن الحقوق التي منحتها تلك الاتفاقيات.

لذا فالحساب المؤسسي متعدد الطبقات. مولت وكالات وزارة الدفاع مرافق ووظائف مهمة. اشترت DCA خدمات NIC لـ DDN. وزودت DARPA وIAB سياسة لإنترنت البحث ونظام النطاقات الناشئ. وأدى USC/ISI وظيفة IANA وفوض أعمال تسجيل الأرقام. وشغلت SRI سجل الإنترنت وDDN-NIC. وامتثل المتقدمون لعملية التسجيل لأنهم سعوا لمعرفات معترف بها. ثم استخدم مشغلو الشبكات وDNS البيانات الناتجة.

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

جامعة رايس: لقطة، وليس ملف معاملة

توضح جامعة رايس كلاً من مدى وصول السجل وحدود أدلة الحالة الباقية.

يدرج RFC 1020 RICE-NET عند 128.42 ويصنفها كشبكة بحثية. ويستخدم RFC 1032 استجابة WHOIS لـrice.eduكمثال على كيفية تحقق مدير النطاق من بيانات التسجيل. يعرض السجل المعروض جامعة رايس وجهات اتصالها وخوادم نطاقها. تثبت هذه السجلات أن معلومات الرقم والنطاق المتعلقة برايس ظهرت في منشورات وخدمات DDN-NIC في نوفمبر 1987.

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

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

لا يمكن وصف النتيجة التشغيلية للسجلات إلا على مستوى النظام. أعطى الرقم المخصص للسجل المشترك معرّفاً فريداً لينشره لـ RICE-NET. ومكّن تفويض نطاق صالح الأنظمة التي تستخدم تسلسل DNS الهرمي المشترك من معرفة أي الخوادم موثوقة لـrice.edu. ولا تثبت الوثائق أن أي رزمة محددة تم توجيهها، أو أن رايس حصلت على اتصال مادي من DDN-NIC، أو أن شبكة أخرى أجبرت على حمل حركة مرور رايس.

لم تثبت أي وثيقة عامة مراجعة نزاعاً خارجياً كاملاً من 1983 حتى 1991 قدم فيه متقدم غير متعاقد ومحدد طلب نطاق أو رقم إلى DDN-NIC، وتلقى قراراً متنازعاً عليه، وطلب مراجعة، وحصل على نتيجة موثقة. وهذا حد على التحليل المتاح، وليس دليلاً على أن النزاعات لم تحدث قط. وبدون مثل هذا الملف، لا يمكن اختبار كيف شرحت SRI قراراً سلبياً، وما إذا كانت DCA أو USC/ISI راجعته، وما العلاج الذي كان موجوداً، أو ما إذا كان لمقدم الطلب حق قابل للتنفيذ.

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

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

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

الرقابة بدون بند علاج مفتوح

يشير السجل الأرشيفي إلى وجود سجلات إدارة من جانب المشتري، لكن المواد العامة المراجعة هنا لا تكشف هيكل العلاجات الكامل.

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

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

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

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

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

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

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

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

إعادة نظر 1990 في المدى

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

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

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

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

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

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

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

لم تنشأ كل هذه التأثيرات من علاقة تعاقد SRI مع DCA. كان جسر تسجيل الأرقام هو تفويض IANA ومشاركة مقدم الطلب في نظام المعرّفات المشترك. وكان جسر تسجيل النطاقات هو هيكل سياسة IAB وDARPA، وتعيين DCA الموثق، وتسلسل DNS الهرمي، وطلب مقدم الطلب للإدراج. وكان جسر قواعد تشغيل DDN هو استخدام DDN والعلاقة الحكومية ذات الصلة. وكان جسر حمل الحركة هو سياسة الشبكة المستخدمة. لم تثبت أي وثيقة عامة مراجعة أن عقد مشتريات SRI دمج هذه العلاقات في سلطة عامة واحدة على كل مشغل معتمد.

السنوات المفقودة وتسليم 1991

تحتوي المرحلة الأخيرة من التسلسل الزمني على أوضح إثبات للاستمرارية وأكبر عدم يقين في المشتريات.

انتهت فترة العقد DCA200-87-C-0020 المبلغ عنها من SRI في 31 يناير 1989. وتظهر طلبات RFC المعاصرة أن SRI استمرت في تشغيل DDN-NIC في 1990 وأوائل 1991. ويصف دليل الأرشيف تقارير تقدم حتى عام 1991. ولم تحدد أي وثيقة عامة مراجعة العقد، أو الخيار، أو التعديل، أو الجسر الذي دعم الاستمرار. ولذلك يبقى أساس المشتريات للفترة من فبراير 1989 إلى نقل 1991 دون حل.

في 25 يونيو 1991، أصبحت DCA هي DISA. وفي سبتمبر، أعلن RFC 1261 أن مركز معلومات الشبكة سينتقل من SRI International في مينلو بارك إلى Government Systems Inc. في شانتيلي في 1 أكتوبر. وحدد الخدمات المقدمة آنذاك لكل من مستخدمي DDN والإنترنت: تسجيل الشبكات والمستخدمين، وتعيين أرقام الشبكات والنطاقات العليا، وخدمات المعلومات عبر الإنترنت، وعمليات مكتب المساعدة، وأرشفة وتوزيع RFCs ومسودات الإنترنت.

كتب الإشعار سكوت ويليامسون وليزلي نوبيل من Network Solutions. وذكر أن SRI ستستمر في الرد على المكالمات والطلبات حتى 30 سبتمبر. ولن تتغير قاعدة بيانات WHOIS من 26 إلى 30 سبتمبر بينما تعلق إجراءات التسجيل وتُنقل قاعدة البيانات الرئيسية إلى GSI. وكان على طلبات البريد والفاكس استخدام عنوان GSI الجديد؛ أما الرسائل الإلكترونية المرسلة إلى صناديق بريد Hostmaster وRegistrar المألوفة فستستمر ويعاد توجيهها حسب الاقتضاء. وستُستأنف أنشطة التسجيل في 1 أكتوبر. واستخدم NIC الجديد خادم Sun 470 SPARCserver يعمل بنظام SunOS 4.1، بدلاً من بيئة TOPS-20 السابقة.

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

قدم رأي محكمة فدرالية محلية في عام 1998،Thomas v. Network Solutions، رواية قانونية لاحقة. ذكرت المحكمة أن Network Solutions حصلت على عقد من الباطن بموجب عقد مشتريات منحته DISA لـ GSI وأن واجباتها شملت تسجيل النطاقات وتعيين أرقام IP. ونقل رأي فدرالي منفصل في 2000 رواية محلفة من مسؤول مؤسسة العلوم الوطنية جورج سترون تصف Network Solutions كمقاول باطن لـ GSI يدعم DDN والإنترنت بموجب عقد مع DISA.

تدعم هذه الروايات اللاحقة وصفاً عالي المستوى لمقاول رئيسي ومقاول باطن: DISA كوكالة حكومية، وGSI كحائز علاقة المشتريات، وNetwork Solutions كمقاول باطن يؤدي أعمال السجل. لكنها لا تكشف رقم الجائزة، أو الإعلان، أو سجل الاختيار، أو العقد الرئيسي الموقع أو عقد الباطن. كما أنها تحتوي على ملخصات استعادية ينبغي ألا تحل محل رواية RFC 1261 المعاصرة للانتقال التشغيلي في 1 أكتوبر.

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

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

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

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

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

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

أدلة مختلفة كان يمكن أن تغير هذه الإجابة. عقد SRI وتعديلاته قد يحدد ممتلكات مقدمة من الحكومة، ومتطلبات تسليم البيانات، ومساعدة عند الإنهاء، أو التزامات مستمرة. وقد يحدد إعلان خلف وجائزة GSI فئة مستخدمي الخدمة، ومعالم الانتقال، وشروط القبول. وقد يحدد عقد الباطن مع Network Solutions تقسيم العمل الفعلي. ولا يمكن استنتاج أي من هذه الشروط من حقيقة أن التسليم نجح.

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

الاعتماد العملي وحدوده

بنهاية الثمانينيات، جلس DDN-NIC عند تقاطع عدة أشكال من الاعتماد. كان بعضها عواقب مباشرة لقواعد التشغيل الحكومية. وجاء بعضها الآخر من التفويض التقني، والتسلسل الهرمي، والتبني المشترك.

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

بالنسبة لمتقدم نطاق خارج تلك الفئة، جاءت النتيجة المباشرة من فضاء الأسماء المشترك. كان الطلب المكتمل وترتيب خادم الأسماء المتوافق شرطين لتفويض تحت النطاق العالي المعني. كان دور DDN-NIC مدعوماً بسياسة IAB وDARPA، وتعيين DCA لأجزاء DDN وDARPA، والسلطة التسلسلية الممنوحة للمسجلين ومديري النطاقات. كان حافز مقدم الطلب هو الحل المعترف به من خلال النظام المشترك.

بالنسبة لمتقدم رقم، حدد RFC 1174 جسراً مختلفاً: كانت وظيفة IANA في USC/ISI قد أودعت مسؤولية تسجيل أرقام الشبكات والأنظمة المستقلة لدى سجل الإنترنت التابع لـ SRI. نشأت قيمة التعيين من التفرد والاعتراف عبر الأنظمة المشاركة. ولم يخلق بحد ذاته مساراً، أو اتصالاً، أو إذناً لاستخدام عمود فقري مدعوم فدرالياً.

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

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

الأدلة أقوى عندما تحدد الجسر بالضبط. ربط RFC 810 التسجيل بشروط تبادل مضيفي وزارة الدفاع لحركة المرور. وربط RFC 920 إنشاء النطاقات بسياسة وتسلسل ARPA-Internet ومجتمع أبحاث DARPA. وربط RFC 1032 التفويض بطلب مكتمل ومسؤوليات إدارة النطاق. وربط RFC 1174 تسجيل الأرقام بتفويض IANA مع فصل التسجيل عن حالة الاتصال وسياسة التوجيه. وأظهر RFC 1261 أن استمرارية الخدمة لمستخدمي DDN والإنترنت تطلبت نقلاً تشغيلياً مداراً.

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

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

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

ما يمكن أن يعنيه العنوان بأمان

تدعم الأدلة إجابة محددة عن ثلاثة أسئلة منفصلة.

داخل سلسلة DDN ووزارة الدفاع، كان لـ DCA دور حكومي موثق وكانت SRI مقاولاً موثقاً. تطلبت مواصفات وأدلة التشغيل التسجيل أو الموافقة لأنشطة محددة في DDN وARPANET وMILNET. وعالج DDN-NIC السجلات، وصان الخدمات، وأوصل الإجراءات نيابة عن DCA. وجاءت قوة هذه الإجراءات من إدارة DCA للشبكة والتزامات المرافق المشمولة. ولأن بيانات العمل وبنود العلاجات ذات الصلة لا تزال غير متاحة، لا يمكن إعادة بناء المحيط التعاقدي الدقيق.

خارج فئة المشترين تلك، قبلت المنظمات واعتمدت على عدة خدمات. سعت لمعرّفات فريدة من سجل الإنترنت، وتقدمت بنطاقات في التسلسل الهرمي المشترك، واستعلمت WHOIS، وحصلت على RFCs، واعتمدت على بيانات خادم الجذر. تضمنت أسبابها تفويض IANA، وسياسة IAB وDARPA، وتعيين DCA المحدود، وامتثال مقدم الطلب لإجراءات التسجيل، والتشغيل البيني التقني، والثقة المتراكمة، والتكلفة العملية للخروج عن نظام واسع الاستخدام. أعطت هذه الجسور DDN-NIC سلطة حقيقية على قرارات تسجيل معينة.

سلطة على مدخل سجل لم تكن سلطة على كل مؤسسة أو شبكة مرتبطة. احتفظ مديرو النطاقات بالمسؤولية داخل نطاقاتهم. وبقيت IANA متميزة عن سجل الإنترنت. وكان لـ DCA وDARPA أدوار مؤسسية مختلفة. وتعيين المعرّف لم يقدم ترابطاً بينياً. وإدراج DNS لم يأمر بكل مسار. وسياسة الاستخدام المقبول لعمود فقري طبقت من خلال استخدام ذلك العمود الفقري، وليس فقط من خلال الظهور في قاعدة بيانات مركزية.

لم تثبت أي وثيقة عامة مراجعة جسراً عالمياً يربط به شراء DCA لخدمات SRI، بمفرده، كل شبكة غير متعاقدة استخدمت السجلات الناتجة. كما أن غياب مثل هذه الوثيقة لا يمحو السلطة الأضيق التي وفرتها سياسة IAB، وكفالة DARPA، وتفويض IANA، وقواعد التسلسل الهرمي، ومشاركة مقدم الطلب.

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

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

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

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

المصادر