Resumen

  • La declaración de calificaciones de SRI de 1988 informó números de contrato, fechas, financiamiento y trabajo, pero no se han localizado copias públicas de los contratos subyacentes, modificaciones y declaraciones de trabajo, dejando sin resolver las obligaciones exactas, los recursos y los períodos superpuestos.
  • La adquisición de DCA respaldó los servicios del NIC dentro de la cadena del DDN y el DoD, mientras que las reglas operativas del DDN, la política de dominios del IAB y DARPA, la delegación de IANA de USC/ISI y la dependencia externa proporcionaron puentes separados y específicos del servicio que no pueden reducirse a un mandato contractual universal.
  • La transferencia de 1991 muestra que el proveedor operativo cambió mientras los datos, los canales de solicitud y los servicios se mantuvieron; no establece los términos de adquisición faltantes, las obligaciones de transición, la propiedad, los costos o los recursos para los usuarios externos.

El relato de un contratista sobre su propio historial

La tabla pública más detallada de números de contrato de DDN-NIC no proviene de un contrato firmado de la Defense Communications Agency, una declaración de trabajo o un informe de inspección gubernamental. Aparece en un documento de SRI International fechado el 27 de octubre de 1988 y preparado para una oportunidad completamente diferente:Qualifications Statement for Solicitation F04701-88-R-0043: Technical Support for Global Positioning System Information Center. El Network Information Systems Center de SRI presentó el documento para demostrar que podía desarrollar y operar un centro de información GPS civil propuesto. Su discusión sobre DDN-NIC fue experiencia corporativa ofrecida en apoyo de esa oferta.

Esa procedencia cambia cómo debe leerse cada entrada de la tabla. SRI informó que DCA200-83-C-0025 se extendió desde el 1 de junio de 1983 hasta el 31 de diciembre de 1985 y tuvo un financiamiento de $3,122,367. Informó que DCA200-84-C-0024 se extendió desde el 15 de junio de 1984 hasta el 31 de enero de 1987, con un financiamiento de $8,128,495. Listó DCA200-87-C-0020 para dos períodos anuales que comenzaban el 1 de febrero de 1987, con $3,772,115 para el primer año y $4,121,252 para el segundo. Las fechas se superponen. No se han localizado copias públicas de los contratos subyacentes, las modificaciones y las declaraciones de trabajo, por lo que la superposición no puede explicarse de manera segura como una opción, un paquete de trabajo separado, un arreglo puente o un cambio en la estructura contractual.

SRI también describió ocho áreas de trabajo, incluidos los servicios centrales de información de red; protocolos y arquitectura de información y bases de datos; control de acceso a la red y registro de usuarios; el sistema de pista de auditoría y facturación del DDN y ARPANET; servicio de nombres y directorio para el Internet del DoD; y la operación de una instalación informática gubernamental. Enumeró WHOIS, servicio de nombres, registro de dominios, distribución de protocolos, una línea directa telefónica, registro de usuarios, servicios de información en línea, publicaciones y software. Al final de la tabla, SRI afirmó que sus entregables se habían completado sin excesos.

Estas declaraciones son evidencia útil de lo que SRI representó sobre su experiencia en 1988. No son hallazgos independientes de que DCA compró cada actividad enumerada bajo cada contrato reportado, que el trabajo cumplió con los criterios de aceptación del gobierno o que cada usuario de Internet se encontraba dentro de la población cubierta por la adquisición. SRI se describía a sí mismo ante un cliente potencial. El propósito del documento recompensaba un relato exhaustivo de la capacidad y el desempeño exitoso. No proporcionaba la distancia institucional de una auditoría o la decisión de aceptación de un oficial de contratación.

Una parte de la cadena reportada tiene corroboración federal separada. El National Technical Information Service cataloga elDDN Protocol Handbook, Volume 1: DoD Military Standard Protocolsde 1985 como un informe técnico de DDN-NIC de SRI producido bajo DCA200-83-C-0025. El registro del NTIS describe un manual para implementadores que planeaban conectar computadoras a la Defense Data Network, incluido ARPANET. Identifica los roles de DCA y la DDN Program Management Office en la estandarización de protocolos y la gestión de configuración. Esto establece que el número de contrato estaba asociado con al menos ese producto documentado. No revela el resto del alcance del contrato, su estructura de pago, sus recursos ni los derechos de las personas que no eran parte del mismo.

La precaución probatoria es especialmente importante porque la declaración de calificaciones de SRI marcó algunos trabajos en su organigrama de 1988 como no cubiertos por el contrato de DCA. Esa anotación advierte contra el tratamiento de todo lo realizado en el mismo centro, por el mismo personal o en las mismas computadoras como parte de una sola adquisición. El trabajo de DDN de SRI, la actividad relacionada con DARPA, las responsabilidades de la comunidad técnica y el desarrollo financiado internamente podían coexistir dentro del Network Information Systems Center sin compartir una base legal idéntica.

La pregunta inicial de adquisición debe, por lo tanto, permanecer más limitada que el inventario de servicios sobreviviente: ¿qué requería DCA que SRI entregara, a quién y bajo qué arreglos de supervisión y reparación? La evidencia pública solo responde partes de esa pregunta. Identifica la agencia contratante, el contratista, tres números de contrato y fechas reportados, al menos un entregable asociado y un cuerpo sustancial de servicios que operaban durante el período. No proporciona los instrumentos firmados necesarios para reconstruir cada obligación.

La cadena de compras que puede establecerse

La principal relación institucional es clara a alto nivel. El Department of Defense proporcionó el entorno gubernamental. DCA administraba la Defense Data Network y contrataba con SRI para el trabajo del NIC. SRI International era el contratista. DDN-NIC era el centro operativo a través del cual SRI suministraba servicios de registro, información y asistencia. Las instalaciones del DDN y los usuarios documentados de ARPANET y MILNET constituían la población para la cual la autoridad operativa gubernamental es más claramente visible.

LaGuide to the SRI ARC/NIC Recordsde 2011 del Computer History Museum describe el archivo sobreviviente como conteniendo propuestas, declaraciones de trabajo, contratos, modificaciones, correspondencia, informes de progreso mensuales e informes de entregables de contrato. Dice que para 1987 el trabajo del NIC consistía en numerosas tareas con líderes de tarea y presupuestos asignados. Se describe que los informes formales mensuales continuaron hasta 1991, mientras que los informes de entregables de contrato cubren desde 1980 hasta 1990. La guía de hallazgos, por lo tanto, identifica los tipos de registros normalmente asociados con la administración de contratos gubernamentales: instrumentos numerados, estructuras de tareas, presupuestos, informes y archivos de modificación.

Una guía de hallazgos no es el contenido de esos archivos. Le dice a un investigador que los registros existen, cómo están organizados y, en algunos casos, cómo el archivista los resumió. No establece la redacción de una declaración de trabajo, la aceptación por parte del gobierno de un entregable, el derecho del contratista al pago ni el recurso por un desempeño defectuoso. La guía fue escrita por Elizabeth Feinler, quien había dirigido el proyecto NIC en SRI. Su conocimiento la hace valiosa como un mapa archivístico e historia institucional, pero no convierte sus resúmenes en hallazgos auditados o decisiones de oficiales de contratación.

La evidencia más sólida de los servicios realmente suministrados proviene de documentos operativos contemporáneos. El RFC 811, emitido en marzo de 1982, describía el Servidor de Nombres de Host como uno de una serie de servicios de nombres mantenidos por el NIC de SRI en nombre de DCA. El RFC 954, publicado en octubre de 1985, identificaba el servidor NICNAME/WHOIS de la misma manera. El registro del manual del NTIS conecta una publicación importante del DDN con un número de contrato reportado. El RFC 1032, emitido por SRI en noviembre de 1987, decía que DCA había designado al NIC para proporcionar servicios de registro de dominios para las porciones del DDN y DARPA de Internet. Para febrero de 1991, el RFC 1206 todavía identificaba a SRI International como el operador de NIC.DDN.MIL, el repositorio de RFCs e Internet Drafts, un proveedor de asistencia al usuario del DDN, el sitio del Registro de Internet y un operador de servicios de dominio y WHOIS.

En conjunto, esos documentos muestran que SRI realizó el trabajo descrito. Identifican servidores en funcionamiento, buzones de correo, soporte telefónico, publicaciones, bases de datos y procedimientos de registro. No revelan qué servicio se cargaba a qué línea de contrato. Un RFC que describe una regla operativa no puede promoverse a una declaración de trabajo, así como la existencia de un servidor público no puede probar el derecho contractual de un tercero a un servicio continuo.

El nombre de la agencia cambia cerca del final del período. DCA retuvo ese nombre hasta el 25 de junio de 1991, cuando la Department of Defense Directive 5105.19 la renombró como Defense Information Systems Agency. Los relatos contemporáneos y posteriores a veces usan los dos nombres de manera laxa al discutir la transición, pero la fecha importa. DCA es el nombre correcto de la agencia para los contratos de SRI reportados en 1983, 1984 y 1987. DISA es el nombre correcto para la agencia identificada en el aviso de transferencia operativa de septiembre de 1991.

Existe una brecha material entre esos puntos. La tabla de calificaciones de SRI de 1988 da el 31 de enero de 1989 como el final del período listado de DCA200-87-C-0020. El RFC 1206 demuestra que SRI todavía operaba el DDN NIC en febrero de 1991, y la guía archivística describe informes mensuales hasta ese año. Ningún instrumento público revisado identifica la opción, extensión, contrato puente, modificación o arreglo sucesor que respaldó el trabajo desde febrero de 1989 hasta la transferencia de 1991.

La brecha no prueba que SRI trabajó sin contrato. Significa que el vehículo de adquisición no se ha establecido a partir de los documentos disponibles para revisión. Una descripción operativa posterior no puede suplir un número de adjudicación faltante, y el servicio continuo no revela si la continuidad dependió de una opción ejercida, una modificación a un acuerdo existente u otra adquisición.

Lo que las reglas de DCA hacían obligatorio

Dentro del entorno del DDN, las acciones de DDN-NIC estaban conectadas a la autoridad operativa gubernamental mediante reglas más específicas que la posición misma del contratista.

El RFC 810, publicado en marzo de 1982, especificaba la tabla de hosts del Internet del DoD y atribuía su mantenimiento al NIC en nombre de DCA. Su tratamiento de los registros del DoD y no del DoD no era simétrico. Los nombres y direcciones de las redes, puertas de enlace y hosts del DoD debían negociarse y registrarse con el NIC antes de su uso y antes de que un host del DoD les pasara tráfico. Durante un período interino, el NIC intentaría mantener información similar para redes y hosts no del DoD si se suministraba y seguía siendo necesaria mientras se desarrollaban servidores de nombres intercomunicados.

Esto era una especificación operativa, no un contrato. Aun así, identifica una fuente concreta de autoridad. Un host del DoD estaba sujeto a las reglas que gobernaban una red administrada por una agencia del DoD. El NIC recibía y mantenía el registro requerido, pero la consecuencia operativa provenía de la posición de DCA sobre la red del DoD y sus instalaciones participantes. SRI no necesitaba un poder regulatorio independiente sobre un host militar cuando DCA podía hacer del registro una de las condiciones bajo las cuales ese host usaba la red.

ElDDN Protocol Handbookde 1985 encaja en el mismo patrón. Su propósito declarado era guiar a los implementadores que conectaban máquinas al DDN. El manual explicaba los requisitos de protocolo del DoD, la gestión de configuración y los roles de DCA y la DDN Program Management Office. Su fuerza sobre una instalación cubierta provenía del lugar de la instalación dentro del programa DDN, no de la disponibilidad pública del manual o la autoría de SRI.

El RFC 954 proporciona otro ejemplo acotado. WHOIS era accesible a través de Internet, y DCA alentaba a los hosts de la red a poner el servicio a disposición de los usuarios. Sin embargo, su lenguaje de registro se concentraba en personas con cuentas en hosts de ARPANET o MILNET que podían pasar tráfico a través del Internet del DoD. Los usuarios del Controlador de Acceso a Terminales de MILNET tenían que estar registrados. El documento daba el buzón de correo y el número de teléfono del registrador, pero no declaraba que toda persona que usara TCP/IP en cualquier lugar tuviera que ingresar al directorio respaldado por DCA.

El servicio podía ser tanto de utilidad pública como oficialmente obligatorio para una población especificada. La accesibilidad pública no convertía a todos los usuarios en beneficiarios contractuales. El registro obligatorio para un usuario de TAC de MILNET no probaba una obligación comparable para un empleado de una red universitaria extranjera.

La supervisión de DCA también aparece en las instrucciones de solicitud del RFC 1032. Si adoptar un nombre de dominio completamente calificado cambiaba el nombre de host oficial de un host de ARPANET o MILNET, el solicitante debía obtener la aprobación de DCA de antemano y permitir tiempo para el procesamiento. El puente administrativo es visible: el host afectado pertenecía a un entorno administrado por DCA; su nombre propuesto cambiaba un registro oficial utilizado en ese entorno; el NIC procesaba la solicitud; y se requería la aprobación de DCA.

Ningún instrumento público revisado establece que el mismo requisito de aprobación gobernara cada nombre de host local en cada red externa. En cambio, el RFC 1032 asignó gran parte de la responsabilidad de los nombres locales a los administradores de dominio y negó un papel central en la adjudicación de disputas organizativas privadas. DDN-NIC ejercía una autoridad real en un límite de registro sin administrar toda la conducta detrás de ese límite.

Ese arreglo no era inherentemente defectuoso. Una agencia gubernamental puede definir los requisitos operativos para su red, designar un proveedor de servicios, exigir a los usuarios cubiertos que presenten información precisa y reservarse la aprobación sobre los cambios en los registros oficiales. La competencia de SRI hizo que ese diseño funcionara a escala creciente. La pregunta sin respuesta comienza donde un usuario no era ni una instalación del DDN ni estaba de otra manera dentro de la cadena de patrocinio gubernamental relevante.

La autoridad proporcionada por la política de Internet

La adquisición no era el único puente entre DDN-NIC y la Internet más amplia. La autoridad positiva conferida por la política técnica debe sopesarse en sus propios términos.

El RFC 920, publicado en octubre de 1984 por Jon Postel y Joyce Reynolds en USC/ISI, se declaró una declaración de política oficial del Internet Activities Board y DARPA. Definió los requisitos para establecer dominios en la ARPA-Internet y la comunidad de investigación de DARPA. Los dominios necesitaban administradores responsables, un servicio de nombres confiable y registro dentro de la jerarquía. El NIC fue listado como agente para los dominios de nivel superior iniciales. DARPA fue identificado como administrador de ARPA, GOV, EDU, COM y ORG; la DDN Program Management Office era el administrador de MIL.

Esta era una designación significativa. Una organización que buscaba un dominio de segundo nivel bajo un dominio de nivel superior administrado por el NIC tenía que trabajar a través de la estructura de registro. El administrador del nivel superior debía estar satisfecho de que se cumplían los requisitos aplicables antes de autorizar el nuevo dominio. Se esperaba que los solicitantes identificaran contactos responsables, describieran sus servidores de nombres y proporcionaran otra información operativa. Sin una delegación aceptada en la jerarquía compartida, el nombre propuesto no sería publicado a través de los datos raíz de esa jerarquía.

El RFC 920 también dividió la autoridad en lugar de concentrarla indiscriminadamente. El propietario de un host elegía a qué dominio buscar ingresar, mientras que un administrador de dominio elegía qué hosts aceptar. Su acuerdo formaba la base administrativa para la posición del host en el espacio de nombres. Los administradores controlaban los nombres dentro de sus propios dominios y podían delegar responsabilidad más abajo en el árbol. El papel central del NIC coexistía con un control local sustancial.

El documento contemplaba expresamente el reemplazo institucional. Observaba que otras entidades podrían ser agentes o registradores más apropiados para algunos dominios y que la responsabilidad debía entonces reasignarse. También decía que no se deseaba la administración permanente del NIC de cada dominio de nivel superior. El IAB y DARPA estaban estableciendo un arreglo inicial viable, no declarando a SRI inamovible.

Para noviembre de 1987, el RFC 1032 describió la implementación en una forma más desarrollada. Decía que el NIC había sido designado por DCA para proporcionar servicios de registro para el sistema de dominios en las porciones del DDN y DARPA de Internet. Identificaba al NIC como registrador de dominios de nivel superior y segundo nivel, administrador de los archivos de zona del servidor raíz en nombre de DARPA y DDN, y administrador temporal de varios dominios de nivel superior nombrados hasta que organizaciones adecuadas pudieran asumirlos.

Un administrador de dominio prospectivo obtenía un cuestionario, suministraba los detalles organizativos y técnicos requeridos y devolvía el formulario completo a HOSTMASTER en SRI. La guía decía que la solicitud debía estar completa antes de que el NIC autorizara el establecimiento del dominio. También describía arreglos de registro alternativos bajo los cuales las organizaciones de gestión de CSNET y UUCP procesaban las solicitudes para sus comunidades y pasaban la información relevante al NIC para su incorporación en la base de datos central y los archivos raíz.

Este procedimiento proporcionó a DDN-NIC una autoridad operativa específica del servicio. El NIC podía requerir una solicitud completa antes de agregar una delegación a los datos raíz que administraba. Podía aplicar reglas de formato de nombre y clasificación dentro de los dominios de nivel superior puestos a su cargo. Un solicitante que buscaba entrar en esos dominios debía seguir el proceso de registro aplicable.

Esa autoridad no derivaba únicamente de la relación de adquisición de DCA con SRI. Descansaba en una combinación de la política del IAB y DARPA, la designación del NIC por parte de DCA para las porciones documentadas de Internet, la asignación de responsabilidad de la jerarquía y la solicitud de inclusión de un solicitante. Tampoco era ilimitada. El RFC 1032 trataba muchas elecciones de nombres como asuntos locales. Decía que el NIC no decidiría qué parte en disputa tenía el derecho subyacente a registrar un nombre para una organización. Los conflictos debían resolverse antes del registro, mientras que el NIC se limitaba a la orientación técnica y el procesamiento.

Los límites no hacían que la decisión de registro fuera intrascendente. Un dominio omitido de la raíz común no podía esperar una resolución normal por parte de los sistemas que seguían esa raíz. Una delegación retrasada o inexacta podía imponer costos sustanciales. Pero esas consecuencias surgían de un servicio de registro controlado dentro de una jerarquía ampliamente adoptada. Ningún instrumento público revisado establece que el proceso de registro también otorgara a SRI autoridad general sobre la red interna de un solicitante, las decisiones de empleo, las relaciones contractuales o las políticas de tráfico.

Números, IANA y el Registro de Internet

La administración de números de Internet siguió otro camino institucional. La distinción entre la función IANA de USC/ISI y la función de Registro de Internet de SRI es esencial porque, de lo contrario, el mismo buzón de correo del personal podría parecer derivar toda la autoridad de la adquisición de DCA.

El RFC 1020, publicado por personal de SRI en noviembre de 1987, anunció que Hostmaster en DDN-NIC había asumido la responsabilidad de asignar números de red IP y números de sistema autónomo. Reconocía la asistencia continua de Jon Postel y Joyce Reynolds en USC/ISI. El documento era un informe de estado oficial que listaba los identificadores asignados; no reproducía el acuerdo que transfirió el trabajo operativo.

El RFC 1174 proporcionó el relato de política contemporáneo en agosto de 1990. Describió la función IANA como realizada en USC/ISI y declaró que IANA tenía autoridad discrecional para delegar porciones de la responsabilidad de identificadores. Para los números de red y de sistema autónomo, decía que la responsabilidad había sido depositada en el Registro de Internet operado por SRI en DDN-NIC. Por lo tanto, SRI era más que un receptor pasivo de formularios. Dentro del arreglo técnico aceptado, era el registro principal para esos identificadores.

Esa delegación era un puente de autoridad positiva. Explica por qué una organización fuera de la población de compras del DDN podía, sin embargo, presentar una solicitud de número a DDN-NIC y tratar el resultado como autoritativo. El solicitante quería un identificador único a nivel mundial reconocido por el sistema común de coordinación de Internet. La función IANA de USC/ISI había puesto la responsabilidad de registro relevante en SRI. Otros operadores consultaban y reutilizaban las asignaciones del registro para evitar colisiones.

El puente aún tenía bordes definidos. El RFC 1174 mantuvo a IANA y al Registro de Internet institucionalmente distintos. USC/ISI realizaba la función central de IANA; SRI realizaba el trabajo de registro delegado. El IAB recomendó que el registro asignara bloques a organizaciones regionales aprobadas y que la autoridad de asignación adicional se distribuyera internacionalmente. DDN-NIC debía seguir siendo un registro predeterminado donde no existiera un registro delegado, mientras que se compartirían copias agregadas de los datos de registro para mejorar el acceso y la redundancia.

El RFC 1174 no establece la base contractual completa para la relación de IANA con DARPA, DCA o SRI. Su declaración de que IANA poseía autoridad de delegación discrecional registra el arreglo de política reconocido por el IAB. No es un sustituto de los acuerdos faltantes de DARPA y DCA. La US Government Accountability Office encontró un problema probatorio comparable en 2016 al examinar los intereses de propiedad del gobierno en funciones históricas de Internet: no se pudieron obtener contratos clave de las décadas de 1970 a 1990, lo que impidió conclusiones confiables sobre los derechos que esos acuerdos habían transmitido.

El relato institucional es, por lo tanto, estratificado. Las agencias del DoD financiaron instalaciones y funciones importantes. DCA adquirió servicios de NIC para el DDN. DARPA y el IAB proporcionaron la política para la Internet de investigación y el sistema de dominios emergente. USC/ISI realizó IANA y delegó el trabajo de registro de números. SRI operó el Registro de Internet y DDN-NIC. Los solicitantes cumplieron con el proceso de registro porque buscaban identificadores reconocidos. Los operadores de red y DNS luego usaron los datos resultantes.

Cada capa importaba. Ninguna suministra la autoridad completa de todas las demás.

Rice University: una instantánea, no un archivo de transacciones

Rice University ilustra tanto el alcance del registro como los límites de la evidencia del caso sobreviviente.

El RFC 1020 enumera RICE-NET en 128.42 y lo categoriza como una red de investigación. El RFC 1032 utiliza una respuesta WHOIS pararice.educomo un ejemplo de cómo un administrador de dominio podía verificar los datos de registro. El registro mostrado identifica Rice University, sus contactos y sus servidores de dominio. Estos registros establecen que la información de números y dominios relacionada con Rice apareció en las publicaciones y servicios de DDN-NIC en noviembre de 1987.

No revelan la solicitud original de Rice, la identidad del funcionario que la presentó, su relación de financiamiento, su ruta de conexión, sus intercambios con Hostmaster o el tiempo requerido para el procesamiento. No muestran una solicitud en disputa, un rechazo, una anulación, un aviso de aprobación formal o una apelación. El RFC 1020 no marca RICE-NET como una de las redes independientes identificadas por un asterisco, por lo que tampoco sería seguro describir a Rice como una red externa no afiliada sobre esa base.

Las instrucciones de registro del RFC 1032 son genéricas. Su presencia junto a un ejemplo WHOIS de Rice no prueba que Rice siguió cada paso descrito en el formulario mostrado o que una correspondencia particular produjo la entrada mostrada. La lista de números y la salida WHOIS son instantáneas del registro. El procedimiento es un procedimiento publicado. No pueden ensamblarse en una narrativa de transacción sin la correspondencia faltante.

La consecuencia operativa de los registros solo puede describirse a nivel del sistema. Un número asignado le dio al registro compartido un identificador único para publicar para RICE-NET. Una delegación de dominio válida permitió a los sistemas que utilizaban la jerarquía DNS común saber qué servidores eran autoritativos pararice.edu. Los documentos no establecen que algún paquete en particular fuera enrutado, que Rice obtuviera conectividad física de DDN-NIC o que otra red fuera obligada a transportar el tráfico de Rice.

Ningún instrumento público revisado establece una disputa externa completa desde 1983 hasta 1991 en la que un solicitante no contratante identificable presentara una solicitud de dominio o número a DDN-NIC, recibiera una decisión impugnada, buscara revisión y obtuviera un resultado documentado. Eso es un límite en el análisis disponible, no evidencia de que nunca ocurrieran disputas. Sin tal archivo, no es posible probar cómo SRI explicaba una decisión adversa, si DCA o USC/ISI la revisaban, qué recurso existía o si el solicitante tenía un derecho exigible.

Lo que sí se puede establecer es la ruta genérica de manejo publicada por el NIC. Un solicitante de dominio suministraba contactos, información del servidor, direcciones de red y otros detalles operativos. El personal del NIC verificaba la presentación para verificar que estuviera completa y en conformidad con la jerarquía aplicable. La aceptación permitía que la delegación se incorporara a los datos del registro y del servidor raíz. Un solicitante de número buscaba un identificador del Registro de Internet. La asignación creaba una entrada reconocida pero no proporcionaba por sí misma la interconexión.

El RFC 1020 hizo explícita esta última separación. Registró asignaciones de números para redes conectadas a la Internet de investigación u operativa y para redes IP independientes. Los administradores de redes independientes aún debían buscar un permiso separado para interconectarse. La asignación de identificadores, la publicación en el registro y el acceso a la red eran decisiones diferentes.

El material de Rice, por lo tanto, no prueba ni compulsión ni insignificancia. Muestra una institución educativa representada en un registro central con identificadores que importaban para la interoperabilidad. No muestra la relación legal a través de la cual Rice ingresó ni una ocasión en la que DDN-NIC ejerciera un poder controvertido sobre ella.

Supervisión sin una cláusula de recurso abierta

El registro archivístico indica que existían registros de administración del lado del comprador, pero el material público revisado aquí no revela la estructura completa de recursos.

La guía de hallazgos del Computer History Museum describe contratos ordenados por número y luego por tipo de documento, incluyendo declaraciones de trabajo, propuestas, modificaciones, correo electrónico y correspondencia. Identifica informes formales de progreso mensuales e informes de entregables de contrato. Dice que el trabajo de 1987 se dividió en tareas con líderes y presupuestos separados. Estas son descripciones de categorías archivísticas, no hallazgos sobre el contenido o el efecto legal de cada documento.

No identifican las consecuencias de niveles de servicio incumplidos. Ningún instrumento público revisado establece un período de subsanación, derecho de retención, ajuste de tarifas, estándar de terminación, cláusula de asistencia para la transición o recurso por daños bajo los arreglos relevantes de SRI. La afirmación de SRI de 1988 de que todos los entregables se habían cumplido sin excesos no puede llenar ese vacío. Es la representación de desempeño del contratista, no una determinación de aceptación firmada por DCA.

La guía de hallazgos también resume episodios que involucran la producción de documentos, un gasto asociado con la base de datos VOID y el proyecto de correo para computadoras personales SAM. Esos resúmenes indican que el archivo contiene material sobre preguntas de financiamiento, preocupaciones gubernamentales y decisiones que afectan el trabajo de SRI. La correspondencia subyacente, las modificaciones de contrato, las decisiones presupuestarias y las acciones de los oficiales de contratación no han sido revisadas. Por lo tanto, los episodios no pueden presentarse como auditorías verificadas, acciones de cumplimiento formales o recursos disponibles para los solicitantes de registro.

El mismo límite se aplica a la referencia de la guía de hallazgos a una queja anónima asociada con SAM. El resumen de un archivista puede identificar una pista de investigación. No establece las acusaciones exactas de la queja, la tarea contractual involucrada, la autoridad de la persona que la recibió, la respuesta de DCA o las condiciones bajo las cuales el trabajo se detuvo o reanudó. En cualquier caso, no fue una apelación documentada por un solicitante de dominio o número.

Incluso si los controles del lado del comprador estuvieran completamente documentados, solo responderían parte de la cuestión de la rendición de cuentas. Un cliente gubernamental puede poseer recursos contractuales contra su proveedor. Una red externa que utiliza un servicio de acceso público no adquiere automáticamente los mismos derechos. Su posición dependería de un acuerdo, un estatus de beneficiario reconocido, un compromiso administrativo u otra fuente de derecho.

El RFC 1032 proporcionaba buzones de correo, una línea directa telefónica y correspondencia con Hostmaster. Ofrecía orientación técnica y anticipaba los intercambios necesarios para completar una solicitud. No describía un tribunal independiente para solicitudes rechazadas. Su política de dejar las disputas de nombres locales a las partes era un límite a la toma de decisiones del NIC, no un sistema de apelaciones. Ningún instrumento público revisado establece daños, créditos de servicio o un derecho formal de revisión para una red extranjera o comercial afectada por una decisión de registro de SRI.

La incertidumbre es de doble filo. La ausencia de una cláusula de apelación abierta no prueba que no existiera un procedimiento de queja. También impide afirmar que los usuarios externos gozaban de continuidad contractual o protección procesal. La dependencia pública puede haber crecido más rápido que los derechos formales visibles en el registro sobreviviente.

La política técnica sí incluía mecanismos para distribuir la responsabilidad. El RFC 920 permitía que los roles de registrador se reasignaran a entidades más apropiadas. El RFC 1032 distribuía la administración hacia abajo en la jerarquía DNS y se negaba a centralizar las disputas locales. El RFC 1174 proponía una mayor delegación del registro de números y una replicación más amplia de los datos del registro. Estos no eran recursos contractuales ni revisión judicial, pero muestran que la arquitectura no requería que un contratista permaneciera como el único centro operativo indefinidamente.

La reconsideración del alcance en 1990

Para 1990, la población de Internet ya no coincidía con las comunidades gubernamentales y de investigación para las que se habían diseñado los procedimientos anteriores. El RFC 1174 describió el crecimiento hacia la industria, la academia y las redes no estadounidenses y propuso cambios tanto en la asignación de identificadores como en el significado del estatus de "conectado".

El documento no recomendaba abolir la coordinación central. Proponía retener a IANA y al Registro de Internet mientras se distribuían bloques de identificadores a otros registros calificados. DDN-NIC continuaría como el registro principal y predeterminado, los datos agregados permanecerían centralizados para su actualización y se compartirían copias. Esto era una reforma de la administración central, no una negación de que DDN-NIC poseyera autoridad operativa.

Su tratamiento del estatus de conectado es igualmente importante. La práctica anterior asociaba la conexión a Internet con la aprobación de una organización patrocinadora del gobierno de EE. UU. El RFC 1174 recomendó eliminar ese estatus de los formularios y bases de datos del registro, permitiendo que las redes registradas ingresaran al DNS sin tener en cuenta una clasificación de conexión única y registrando en su lugar las políticas de acceso, tránsito y uso aceptable de cada red.

La propuesta reconocía un límite que la adquisición por sí sola no podía gestionar. Un número de red podía ser único a nivel mundial sin que su titular tuviera derecho a usar una red troncal en particular. Un dominio podía aparecer en el DNS sin requerir que cada operador enrutara tráfico hacia él. Una red patrocinada por el gobierno federal podía hacer cumplir sus criterios de acceso en el tráfico que cruzaba sus instalaciones. Otras redes podían tomar sus propias decisiones de interconexión y tránsito.

El RFC 1174 también decía que era inapropiado exigir a cada red no estadounidense que siguiera los criterios de acceso y uso de EE. UU. Los criterios federales podían gobernar el tráfico que utilizaba redes patrocinadas por el gobierno federal. Esto respondía directamente al crecimiento internacional: el control sobre una instalación suministrada no se convertía automáticamente en control sobre todas las redes registradas.

El registro aún ejercía un poder consecuente. Decidía si una solicitud de identificador se ajustaba a sus procedimientos, registraba las asignaciones, mantenía la base de datos y suministraba información utilizada por otros operadores. La inclusión en el DNS era lo suficientemente importante como para que el IAB recomendara separarla del estatus de conexión patrocinado por el gobierno. Esa recomendación habría sido innecesaria si las decisiones del registro no tuvieran efecto.

La dependencia externa no era voluntaria en un sentido sin fricciones. Una organización que deseaba interoperar ampliamente enfrentaba una fuerte presión para obtener números únicos y delegaciones DNS reconocidas. Elegir una dirección conflictiva o una raíz no reconocida podía aislarla de los sistemas a los que quería llegar. El registro común tenía efectos de red, experiencia acumulada y el apoyo de instituciones gubernamentales y técnicas influyentes.

Esos efectos no surgieron todos de la relación contractual de SRI con DCA. El puente para el registro de números era la delegación de IANA y la participación del solicitante en el sistema común de identificadores. El puente para el registro de dominios era la estructura de políticas del IAB y DARPA, la designación documentada de DCA, la jerarquía DNS y la solicitud de inclusión del solicitante. El puente para las reglas operativas del DDN era el uso del DDN y la relación gubernamental relevante. El puente para el transporte de tráfico era la política de la red que se estaba utilizando. Ningún instrumento público revisado establece que el contrato de adquisición de SRI fusionara estas relaciones en una autoridad general sobre cada operador que dependía.

Los años perdidos y la transferencia de 1991

La última fase de la cronología contiene tanto la demostración más clara de continuidad como la mayor incertidumbre en materia de adquisiciones.

El período reportado de DCA200-87-C-0020 de SRI terminó el 31 de enero de 1989. Los RFCs contemporáneos muestran que SRI continuó operando DDN-NIC en 1990 y principios de 1991. La guía del archivo describe informes de progreso hasta 1991. Ningún instrumento público revisado identifica el contrato, opción, modificación o adjudicación puente que respaldó la continuación. La base de adquisición para el período desde febrero de 1989 hasta la transferencia de 1991, por lo tanto, sigue sin resolverse.

El 25 de junio de 1991, DCA se convirtió en DISA. En septiembre, el RFC 1261 anunció que el Network Information Center se trasladaría de SRI International en Menlo Park a Government Systems Inc. en Chantilly el 1 de octubre. Identificó los servicios que entonces se ofrecían tanto a los usuarios del DDN como de Internet: registro de redes y usuarios, asignación de números de red y dominios de nivel superior, servicios de información en línea, operaciones de mesa de ayuda y archivos y distribución de RFC e Internet-Drafts.

El aviso fue escrito por Scott Williamson y Leslie Nobile de Network Solutions. Declaraba que SRI continuaría respondiendo llamadas y solicitudes hasta el 30 de septiembre. La base de datos WHOIS no se modificaría del 26 al 30 de septiembre mientras se suspendían las acciones de registro y la base de datos maestra se transfería a GSI. Las solicitudes por correo postal y fax debían usar la nueva dirección de GSI; los mensajes electrónicos enviados a los conocidos buzones de Hostmaster y Registrar continuarían y serían redirigidos según correspondiera. La actividad de registro se reanudaría el 1 de octubre. El nuevo NIC utilizaba un Sun 470 SPARCserver ejecutando SunOS 4.1, reemplazando el entorno TOPS-20 anterior.

Estos detalles establecen una transferencia operativa de proveedor. Los datos se movieron. Las direcciones, los números de teléfono y la infraestructura informática cambiaron. Las solicitudes se suspendieron, redirigieron y reanudaron. El aviso también establece que DISA y GSI estaban públicamente asociadas con la transición y que el personal de Network Solutions participó en la implementación o comunicación del servicio sucesor.

Una opinión de un tribunal federal de distrito de 1998,Thomas v. Network Solutions, proporcionó un relato legal posterior. El tribunal informó que Network Solutions había obtenido un subcontrato bajo un contrato de adquisición adjudicado a GSI por DISA y que sus deberes incluían el registro de dominios y la asignación de números IP. Una opinión federal separada de 2000 citó un relato jurado del funcionario de la National Science Foundation, George Strawn, que describía a Network Solutions como subcontratista de GSI apoyando el DDN e Internet bajo un contrato de DISA.

Esos relatos posteriores respaldan una descripción de alto nivel de contratista principal y subcontratista: DISA como la agencia gubernamental, GSI como el titular de la relación de adquisición y Network Solutions como subcontratista que realizaba el trabajo de registro. No revelan el número de adjudicación, la solicitud, el registro de selección, el contrato principal firmado o el subcontrato. También contienen resúmenes retrospectivos que no deberían desplazar el relato contemporáneo del RFC 1261 sobre la transferencia operativa del 1 de octubre.

Ningún instrumento público revisado establece si la selección de GSI resultó de una recompetencia, una adjudicación de sucesor ordinaria u otro mecanismo de adquisición. Ningún instrumento público revisado proporciona una cláusula de terminación para SRI, una obligación de asistencia para la transición, la propiedad gubernamental de los datos del registro, los términos de la licencia de software, los niveles de servicio, los costos de migración o los derechos de los usuarios externos. El movimiento de la base de datos maestra muestra que la transferencia ocurrió. No prueba la regla contractual que requería o permitía la transferencia.

No se debe hacer que la transferencia tenga más significado legal del que permite su evidencia. Demuestra que el proveedor operativo cambió mientras los servicios, los buzones, los registros maestros y las expectativas públicas se mantuvieron. No demuestra por qué SRI estaba legalmente obligado a cooperar, quién era dueño de cada componente de software, qué parte asumió los costos de transición o qué recurso habría tenido un registrante externo si la transferencia hubiera fallado.

La población de servicio también requiere cuidado. El RFC 1261 se dirigía tanto a los usuarios del DDN como de Internet, demostrando que la transición operativa se diseñó en torno a una comunidad más amplia que las instalaciones militares. Esa declaración no establece que todos esos usuarios fueran beneficiarios contractuales. Un gobierno puede comprar un servicio puesto a disposición del público sin otorgar a cada usuario el derecho de hacer cumplir la adquisición.

El logro observable fue sustancial. La actividad de registro se pausó por un período definido en lugar de abandonarse. La base de datos maestra se transfirió, los canales de comunicación se redirigieron y los servicios se programaron para reanudarse bajo un nuevo operador. La transición hizo visible la dependencia porque la continuidad requería un trabajo técnico deliberado. También demostró que la operación podía ser transferida de SRI a otro proveedor.

Lo que sobrevivió a la transferencia no puede atribuirse con confianza a una sola fuente legal. Los nombres de los servicios sobrevivieron. Las direcciones electrónicas familiares fueron redirigidas. Los datos del registro se mantuvieron. Se dijo a los usuarios que esperaran un impacto mínimo. Sin embargo, ningún instrumento público revisado establece si esos resultados se debieron a deberes contractuales de transición, derechos de propiedad del gobierno, cooperación negociada para la ocasión, práctica profesional o alguna combinación de ellos.

El contraejemplo planteado por el registro de adquisiciones debe, por lo tanto, permanecer preciso. Si DCA o DISA hubieran reemplazado a SRI mientras las redes externas seguían dependiendo del registro, los documentos sobrevivientes muestran que la continuidad operativa habría requerido el movimiento de datos, la redirección de solicitudes, la comunicación con los usuarios y la preservación de los registros de identificadores reconocidos. No establecen qué parte podía legalmente obligar a esas acciones, qué datos o software eran propiedad del gobierno, qué pago acompañó la transferencia o qué usuarios podían exigir el cumplimiento.

Una evidencia diferente podría cambiar esa respuesta. El contrato de SRI y sus modificaciones podrían identificar la propiedad suministrada por el gobierno, los requisitos de entrega de datos, la asistencia para la terminación o las obligaciones continuas. Una solicitud sucesora y la adjudicación a GSI podrían definir la población del servicio, los hitos de transición y las condiciones de aceptación. El subcontrato de Network Solutions podría identificar la división real del trabajo. Ninguno de esos términos puede inferirse del hecho de que la transferencia tuvo éxito.

El RFC 1261 es, no obstante, importante porque demuestra que la dependencia externa era una preocupación operativa más que una posibilidad abstracta. El aviso se dirigía a los usuarios del DDN y de Internet, anticipaba interrupciones, preservaba las rutas familiares de solicitud electrónica y programaba un breve congelamiento de la base de datos. El servicio se estaba gestionando como infraestructura compartida aunque la posición legal de cada usuario externo no se revela en el aviso.

Dependencia práctica y sus límites

A finales de la década de 1980, DDN-NIC se encontraba en la intersección de varias formas de dependencia. Algunas eran consecuencias directas de las reglas operativas gubernamentales. Otras provenían de la delegación técnica, la jerarquía y la adopción común.

Para un usuario cubierto de DDN, ARPANET o MILNET, la obligación relevante podía ser explícita en una especificación operativa o instrucción de gestión. Un host podía tener que registrar su nombre oficial, obtener aprobación para un cambio o suministrar información precisa del usuario porque el administrador gubernamental de la red lo requería. SRI manejaba el registro, pero la relación vinculante pasaba por la instalación administrada por el gobierno.

Para un solicitante de dominio fuera de esa población, la consecuencia inmediata provenía del espacio de nombres compartido. Una solicitud completa y un arreglo de servidor de nombres conforme eran condiciones para una delegación bajo el dominio de nivel superior relevante. El papel de DDN-NIC estaba respaldado por la política del IAB y DARPA, la designación de DCA para las porciones del DDN y DARPA, y la autoridad jerárquica asignada a los registradores y administradores de dominio. El incentivo del solicitante era la resolución reconocida a través del sistema común.

Para un solicitante de número, el RFC 1174 identificaba un puente diferente: la función IANA de USC/ISI había depositado la responsabilidad del registro de números de red y sistemas autónomos en el Registro de Internet de SRI. El valor de la asignación surgía de la unicidad y el reconocimiento en todos los sistemas participantes. No creaba por sí misma una ruta, una conexión o un permiso para usar una red troncal patrocinada por el gobierno federal.

Para un operador que consultaba los registros del registro, la dependencia podía ser indirecta. El operador utilizaba números, nombres y contactos publicados porque la coordinación reducía las colisiones y hacía viable la comunicación. Esa dependencia podía hacer que un error en el registro fuera consecuente incluso sin un contrato directo entre el operador y SRI. Aún así, no significaba que cada decisión política del operador hubiera sido delegada al registro.

Estas relaciones no son intercambiables. El alcance formal se refiere a la población y las tareas identificadas por un arreglo gubernamental. La dependencia técnica se refiere a si un sistema puede funcionar de manera conveniente o confiable sin un registro común. La convención de interoperabilidad se refiere a las prácticas compartidas por las cuales los sistemas independientes reconocen los identificadores. La aceptación institucional se refiere al peso que los operadores dan a las asignaciones respaldadas por organismos técnicos establecidos. La dependencia heredada se refiere a la dependencia que se acumula porque los participantes anteriores se construyeron en torno al servicio.

La evidencia es más sólida cuando identifica el puente exacto. El RFC 810 vinculaba el registro a las condiciones bajo las cuales los hosts del DoD intercambiaban tráfico. El RFC 920 vinculaba el establecimiento de dominios a la política y jerarquía de la ARPA-Internet y la comunidad de investigación de DARPA. El RFC 1032 vinculaba la autorización a una solicitud completa y las responsabilidades de la administración del dominio. El RFC 1174 vinculaba el registro de números a la delegación de IANA mientras separaba el registro del estatus de conectado y la política de enrutamiento. El RFC 1261 mostró que la continuidad del servicio para los usuarios del DDN e Internet requería una transferencia operativa gestionada.

Ningún instrumento público revisado establece que uno de estos puentes contuviera silenciosamente a todos los demás. Una solicitud de dominio no era un acuerdo general para obedecer todas las reglas del DDN. Una asignación de número de red no era permiso para usar todas las redes troncales. La dependencia de WHOIS no convertía al operador que consultaba en un beneficiario contractual. La publicación en una base de datos compartida no transfería el control de la red interna de una organización a SRI.

Lo contrario también es cierto. La ausencia de una cláusula de adquisición universal no hace que las decisiones del NIC sean opcionales en cada sentido práctico. Una organización que buscaba un dominio reconocido bajo un dominio de nivel superior administrado por el NIC no podía simplemente ignorar el procedimiento del registrador y esperar que la misma delegación apareciera en la jerarquía compartida. Una red que buscaba un número único del Registro de Internet delegado tenía que someterse a su proceso de asignación. La autoridad era limitada, pero era real donde el límite del servicio era real.

Esta es la razón por la que el estatus de contratista no es ni una acusación ni una explicación completa. SRI podía prestar un servicio competente, confiable y ampliamente dependiente bajo el patrocinio del gobierno. Su personal podía ejercer un juicio sustancial al verificar las solicitudes, mantener los datos, coordinar los contactos y operar los servidores. La cuestión de gobernanza no es si ese trabajo importaba. Es qué principal autorizaba cada acción, qué usuarios estaban cubiertos por las reglas de ese principal y qué instituciones adicionales conectaban el servicio con personas fuera de la cadena de compras.

Lo que el título puede significar con seguridad

La evidencia respalda una respuesta limitada a tres preguntas separadas.

Dentro de la cadena del DDN y el DoD, DCA tenía un papel gubernamental documentado y SRI era un contratista documentado. Las especificaciones operativas y los manuales requerían registro o aprobación para actividades definidas del DDN, ARPANET y MILNET. DDN-NIC procesaba registros, mantenía servicios y comunicaba procedimientos en nombre de DCA. La fuerza de esas acciones provenía de la administración de la red por parte de DCA y de las obligaciones de las instalaciones cubiertas. Debido a que las declaraciones de trabajo y las cláusulas de recurso relevantes permanecen indisponibles, no se puede reconstruir el perímetro contractual exacto.

Fuera de esa población de compras, las organizaciones aceptaban y dependían de varios servicios. Buscaban identificadores únicos en el Registro de Internet, solicitaban dominios en la jerarquía compartida, consultaban WHOIS, obtenían RFCs y dependían de los datos del servidor raíz. Sus razones incluían la delegación de IANA, la política del IAB y DARPA, la designación limitada de DCA, el cumplimiento del solicitante con los procedimientos de registro, la interoperabilidad técnica, la confianza acumulada y el costo práctico de apartarse de un sistema ampliamente utilizado. Esos puentes le daban a DDN-NIC una autoridad real sobre decisiones de registro particulares.

La autoridad sobre una entrada del registro no era autoridad sobre cada institución o red asociada. Los administradores de dominio conservaban la responsabilidad dentro de sus dominios. IANA permanecía distinta del Registro de Internet. DCA y DARPA tenían roles institucionales diferentes. La asignación de identificadores no proporcionaba interconexión. La inclusión en el DNS no ordenaba cada ruta. La política de uso aceptable de una red troncal se aplicaba a través del uso de esa red troncal, no meramente por aparecer en una base de datos central.

Ningún instrumento público revisado establece un puente universal por el cual la compra de los servicios de SRI por parte de DCA, por sí sola, obligara a cada red no contratante que utilizaba los registros resultantes. La ausencia de dicho instrumento tampoco borra la autoridad más limitada proporcionada por la política del IAB, el patrocinio de DARPA, la delegación de IANA, las reglas de jerarquía y la participación del solicitante.

El registro de adquisiciones es demasiado incompleto para respaldar una conclusión legal más amplia. Los contratos reales podrían revelar más: una población comprada más amplia, compromisos interinstitucionales, derechos de datos, requisitos de transición o recursos definidos. Un archivo de solicitud externa podría mostrar cómo se manejó una decisión impugnada. Hasta que se produzcan esos instrumentos, los deberes, derechos y recursos no pueden deducirse de los RFCs, los resúmenes de archivo o las historias institucionales posteriores.

En ese sentido disciplinado, DDN-NIC era un contratista, no una constitución. La frase no significa que el centro careciera de autoridad o legitimidad. Significa que el estatus de contratista explica la prestación de un servicio respaldado por el gobierno y parte del poder ejercido dentro de la cadena de compras, mientras que la autoridad en otros lugares debe rastrearse a través de relaciones adicionales y específicas del servicio.

Ese relato le da a DDN-NIC el crédito adecuado. SRI operó una infraestructura importante durante un período de rápido cambio institucional y técnico. Su personal mantuvo registros, directorios, publicaciones, canales de soporte y servidores utilizados más allá de la población militar más reducida. Los servicios eran lo suficientemente valiosos como para que su transferencia en 1991 requiriera la suspensión de las acciones de registro, el movimiento de la base de datos maestra, la redirección de solicitudes y un cambio coordinado de la infraestructura del host.

La lección de gobernanza radica en esa combinación de logros y documentación incompleta. Una administración exitosa puede convertirse en infraestructura común antes de que los derechos de cada parte dependiente sean visibles en los registros públicos. La dependencia técnica puede dar a un contratista una gran influencia práctica. No elimina la necesidad de identificar al principal, la función delegada, la población cubierta, el mecanismo de revisión y el límite más allá del cual otra institución debe suministrar autoridad.

Fuentes