La tabla de hosts antes del mercado: ¿quién autorizó el primer libro mayor de Internet?

Resumen

• La tabla de hosts temprana adquirió autoridad práctica a través de una cadena limitada: ARPA contrató el Centro de Información de Red para ARPANET, SRI mantuvo el registro común, los sitios participantes suministraban y consumían información de los hosts, y posteriormente DCA incorporó el servicio a un entorno operativo del Departamento de Defensa.
• El RFC 810 publicó un requisito previo de registro para los nombres y direcciones utilizados en relación con el tráfico cursado por los hosts del DoD, pero la especificación conservada no demuestra monitoreo, rechazo de paquetes, sanciones, tasas de cumplimiento ni ninguna comunicación bloqueada en particular.
• El registro público no proporciona los contratos iniciales completos, los archivos de solicitudes de la tabla de hosts, las decisiones disputadas, los resultados de correcciones, los registros de anulaciones, los informes de aplicación ni los recursos necesarios para establecer una discrecionalidad ilimitada del NIC o un mandato público que se extendiera a todas las redes externas.

El 8 de marzo de 1974, el Centro de Información de Red solicitó a todos los sitios de ARPANET que cambiaran una tabla de hosts local. La instrucción apareció enRFC 620, “Solicitud de actualizaciones de la tabla de hosts del monitor”, emitido por Bill Ferguson del Centro de Investigación de Aumento de SRI. Los servicios del NIC se habían trasladado aOFFICE-1, en el sitio de red 53 en notación octal. El sitio 2 seguía siendoSRI-ARC, pero su alias pasaría a serARC; el alias familiarNICdebía apuntar en su lugar al sitio 53. El aviso proporcionaba las entradas exactas para las tablas del monitor TENEX y pedía a los sitios que ejecutaban otros sistemas operativos que hicieran cambios equivalentes.

El RFC 620 registra una instrucción, no un caso de cumplimiento observado. No identifica a ningún operador individual que llevara a cabo el trabajo, a ningún sitio que no lo hiciera ni a ninguna interrupción resultante. No obstante, el operador es un papel necesario implícito en el documento: alguien en cada sitio debía modificar el mapeo utilizado localmente de la manera adecuada para ese sistema operativo. Si una tabla permanecía obsoleta, seguiría asociandoNICcon el sitio 2 y podría dirigir un intento basado en el nombre lejos del servicio NIC previsto. Esa consecuencia se deriva del cambio de mapeo, pero el RFC no informa de un fallo real de búsqueda o una conexión mal dirigida.

El aviso expone la estructura administrativa que subyace a un nombre aparentemente simple. SRI podía anunciar la nueva asociación, pero el anuncio no reescribía todas las máquinas remotas. Un sitio tenía que recibir la instrucción, interpretarla y modificar su propio sistema. La denominación compartida funcionaba cuando el registro mantenido, el canal de distribución y la implementación local convergían.

El 25 de marzo de 1974,RFC 627anunció un mecanismo de distribución más regular. El archivo ASCII en línea de nombres oficiales de hosts estaba disponible enOFFICE-1, cuya dirección aparecía como 43 en notación decimal, equivalente al 53 octal utilizado en el RFC 620. El NIC mantendría el archivo e incorporaría adiciones o cambios semanalmente. Cada host de la red era responsable de recuperar la nueva información mediante el Protocolo de Transferencia de Archivos. Los cambios, adiciones, correcciones y comentarios podían dirigirse a Elizabeth “Jake” Feinler a través del correo de red, teléfono o el sistema de identificación del NIC.

Esos dos documentos de marzo no conservan una transacción completa de solicitud a decisión. No obstante, pueden combinarse con registros anteriores y posteriores para establecer una reconstrucción compuesta mínima, siempre que sus fechas permanezcan separadas.

En 1971, un host seleccionaba un nombre formal preferido a través de su enlace bajo el procedimiento propuesto enRFC 273. El enlace transmitía la elección; el documento no establece que un enlace técnico poseyera personalmente autoridad para tomar todas las decisiones organizativas del sitio. El esquema de nombres propuesto esperaba que los alias fueran únicos dentro de la comunidad de la red y contemplaba discusión si se seleccionaban nombres duplicados o excesivamente largos. No especificaba un veto del NIC, un test de rechazo, una regla de decisión final, una anulación ni una apelación.

En enero de 1974,RFC 608describía el nombre oficial de host como una cadena obtenida mediante negociación entre el host y el NIC. Establecía restricciones de caracteres y formato, identificaba el archivo fuente NLS de Feinler, y proponía la generación periódica de una edición ASCII legible por máquina. No explicaba cómo terminaban las negociaciones impugnadas ni quién prevalecía cuando la discusión fracasaba.

En marzo de 1974, el RFC 627 estableció el archivo disponible, la incorporación semanal de actualizaciones, un canal de corrección y la responsabilidad de cada host de obtener nueva información. Solo en 1982RFC 810declaró explícitamente que el usuario de la tabla de hosts del DoD era responsable de traducirla al formato local que fuera necesario. Sería inexacto comprimir estas declaraciones de 1971, 1974 y 1982 en una sola rutina observada o asignar cada paso al mismo funcionario.

El compuesto defendible es, por tanto, modesto. Un host comunicaba su nombre preferido a través de un enlace. Las convenciones publicadas regían la forma de ese nombre, se esperaba la unicidad de los alias, y las elecciones duplicadas o largas podían provocar discusión. SRI mantenía una fuente a partir de la cual generaba un archivo común. Los sitios recuperaban el archivo e incorporaban su contenido en los sistemas locales. Para 1982, la responsabilidad del usuario por la traducción local se declaraba expresamente. Lo que sucedía cuando un nombre propuesto seguía en disputa, cuando una corrección era impugnada o cuando un sitio rechazaba una instrucción no puede recuperarse solo de los RFC procedimentales.

Esta es la primera frontera en la autoridad de la tabla de hosts. El registro común podía determinar qué nombre reconocía un sistema participante sin decidir si la computadora subyacente existía, si se había instalado una línea física o si una organización había sido admitida en la red. Sus efectos eran operativos y, a veces, graves para el uso basado en nombres, pero no eran idénticos al control sobre toda la conectividad.

Cuatro tablas divergentes y el caso a favor de un archivo común

El archivo de hosts en línea abordaba un problema de coordinación observado. En diciembre de 1973,RFC 606describía cuatro sistemas TENEX accesibles—SRI-ARC,BBN-TENEX,USC-ISIyPARC-MAXC—cuyos mapeos entre nombres de hosts y direcciones diferían. Ninguno era completo, y el autor creía que cada uno divergía en algún aspecto de la lista oficial.

Esa evidencia no debe inflarse para afirmar que cada sitio de ARPANET tenía una tabla inexacta. Establece divergencia en cuatro sistemas nombrados. Incluso ese hallazgo limitado bastaba para demostrar el costo del mantenimiento separado. Una persona que se moviera entre esas máquinas podía encontrar respuestas diferentes. Un programa escrito contra un conjunto local podía fallar al trasladarse a otro. Un host recién agregado o renombrado podía ser reconocido en un sitio pero permanecer desconocido en otro.

El RFC 606 proponía un archivo generado centralmente, legible por máquina y mantenido por el NIC. Distinguía los dos hechos centrales de una entrada —nombre de host y dirección de host— de atributos opcionales como el estado del host, el comportamiento del protocolo y los alias. Su autor advertía que los atributos no tenían por qué ser completos y no debían reemplazar la negociación del protocolo, el boca a boca u otras formas de descubrir las propiedades de un host. La propuesta era deliberadamente específica: buscaba resolver listas locales incompatibles, no establecer una constitución integral para la participación en la red.

El RFC 608 aceptó la idea del archivo central e informó de que contaba con el apoyo de la oficina de Técnicas de Procesamiento de la Información de ARPA. Feinler mantenía la fuente en el formato NLS de SRI, mientras que un programa debía generar periódicamente el archivo de distribución ASCII. Inicialmente, las entradas generadas contendrían el nombre oficial, la dirección decimal del host y el estado. Se podría añadir otra información a medida que los datos estuvieran disponibles. El documento también permitía un prefijo de red para hosts fuera de ARPANET, lo que muestra que los autores ya contemplaban un conjunto de comparación más amplio que la población de hosts de ARPANET. No identifica cada host externo realmente incluido.

La distinción entre fuente y distribución era importante. NLS era un sistema de SRI utilizado para mantener información estructurada. La edición ASCII estaba diseñada para ser recuperada y procesada por hosts heterogéneos. SRI-ARC era el contexto organizativo y de computación desde el que se emitieron varias de estas notificaciones, mientras queOFFICE-1se convirtió en la máquina que atendía a los usuarios del NIC y al archivo de hosts publicado en marzo de 1974. Documentos posteriores utilizaronSRI-NICpara el host que proporcionaba la tabla del DoD y el servicio de nombres. Estas etiquetas marcan cambios técnicos y organizativos; no deben tratarse como nombres intercambiables para una máquina inmutable.

El RFC 627 convirtió la propuesta en un servicio anunciado. Animaba a los hosts a utilizar los nombres oficiales en sus monitores y hacía a cada host responsable de recuperar el archivo. Los alias eran opcionales, y se animaba a los sistemas que proporcionaban traducción de nombre a dirección a utilizarlos, pero no se requería. El documento proporcionaba canales para adiciones y correcciones, pero la existencia de un canal no prueba el tiempo necesario, la evidencia exigida ni el recurso disponible cuando una solicitud era denegada.

La arquitectura seguía siendo distribuida en el punto de uso. SRI mantenía el archivo de referencia, pero los sitios remotos decidían cuándo recuperarlo y cómo instalarlo. Un maestro recién corregido podía coexistir con copias locales obsoletas. Un operador podía complementar un archivo oficial con un alias local. Una persona que conociera una dirección numérica podía eludir un nombre faltante. La tabla reducía la inconsistencia sin convertirse en la subred de conmutación de paquetes en sí misma.

Una entrada errónea aún podía tener efectos materiales. Un programa basado en nombres podía dirigir el tráfico hacia la dirección registrada en lugar de a la máquina prevista. Una entrada ausente podía dejar al software incapaz de traducir el nombre solicitado. Una actualización local retrasada podía preservar un resultado obsoleto. El comportamiento exacto dependía del sistema operativo y la aplicación locales. Los RFC no justifican una afirmación universal de que cada omisión producía desconexión o que cada entrada inexacta producía el mismo error.

La reubicación de marzo ilustra la proposición más limitada. Después de queNICse trasladara aOFFICE-1, un sitio que implementara el cambio del RFC 620 asociaría el alias con el sitio 53. Un sitio obsoleto podía seguir asociándolo con el sitio 2. El traslado del servicio de SRI ocurría independientemente de la tabla remota, mientras que la utilidad del alias compartido dependía de la adopción remota. El registro era relevante porque otras máquinas actuaban en consecuencia.

Los nombres empezaban con los hosts, no con un veto ilimitado del NIC

El archivo común no surgió de una regla establecida que permitiera al NIC asignar cualquier nombre que deseara. La discusión del RFC de 1971 registra un desacuerdo sustancial sobre la denominación.

RFC 226hizo circular un conjunto propuesto de mnemónicos e invitó a plantear objeciones. Siguieron sugerencias contrapuestas. Algunos participantes preferían indicativos cortos; otros querían nombres que preservaran las identidades institucionales y de proyecto. El debate no era meramente cosmético. Los nombres aparecían en comandos, documentos y hábitos de los usuarios. Por tanto, una regla de denominación distribuía tanto inconvenientes como reconocimiento, además de caracteres.

EnRFC 237, el NIC argumentó que era un organismo lógico para mantener el estándar de nombres y propuso asignar nombres a los nuevos hosts una vez que el Grupo de Trabajo de la Red hubiera acordado la sintaxis y la lista actual. Esa era una propuesta institucional del operador del servicio. Es evidencia de lo que el NIC quería que fuera su papel, no de que cada organización conectada o una autoridad pública superior aceptara la totalidad de la reivindicación.

El RFC 273 respondió al fracaso de las propuestas anteriores para lograr aceptación. Decía que los hosts, a través de sus enlaces, debían elegir sus propios nombres formales, posiblemente sujetos a discusión si seleccionaban nombres duplicados o extra largos. Se esperaba que los hosts de una misma institución utilizaran el mismo mnemónico institucional. Un alias debía ser único dentro de la comunidad de la red.

El lenguaje establece la elección local y la posibilidad de discusión central. No define quién podía emitir un rechazo final. Un duplicado frustraría el propósito de un alias compartido, pero la incompatibilidad técnica por sí sola no revela el recurso administrativo. El NIC podría haber persuadido a un sitio para que eligiera otro nombre; un patrocinador podría haber intervenido; los sitios podrían haber aceptado una convención informal; o algún desacuerdo podría haber quedado sin resolver. Se necesitaría un archivo de casos completo para distinguir esas posibilidades.

RFC 289, emitido en diciembre de 1971, informó de que casi todos los sitios habían respondido con los nombres deseados. Su título, “Lo que esperamos que sea una lista oficial de nombres de hosts”, conserva el carácter provisional del ejercicio. La lista emergente reflejaba la solicitud y la respuesta de los sitios dentro de una comunidad ARPANET limitada. No era ni una invención privada unilateral ni el resultado de una delegación pública mundial.

El papel del enlace también requiere cuidado. El RFC 273 utilizaba a los enlaces como el canal a través del cual los hosts elegían y comunicaban los nombres. Unaguía posterior del Computer History Museum sobre los registros SRI ARC/NICdice que los enlaces técnicos generalmente no tenían autoridad para hablar en nombre de la administración del sitio. La guía del archivo describe la creación posterior de un rol de Administrador de Host cuyo titular podía autorizar acciones del sitio. Dado que la guía abarca un período más largo, no puede simplemente proyectarse hacia atrás a cada intercambio de 1971. Sin embargo, advierte contra tratar “enlace” como sinónimo de ejecutivo institucional.

Lo más que puede decirse con seguridad es que el host era el elector originario en el procedimiento publicado de 1971, el enlace era el canal de comunicación y el NIC mantenía el resultado compartido. La sintaxis y la unicidad esperada limitaban lo que podía funcionar en el espacio de nombres común. Los documentos no revelan un sistema de adjudicación integral.

Esa discrecionalidad limitada era, sin embargo, significativa. Una vez que un nombre aparecía en documentos y archivos legibles por máquina, los usuarios de otros lugares podían confiar en él. Un host podía cambiar su nombre, pero hacerlo imponía costos en el software, la documentación y el conocimiento local. La estabilidad se convirtió en una fuente de autoridad práctica. El centro no necesitaba un poder legal amplio para hacer que su respuesta mantenida fuera difícil de ignorar.

El contrato de servicios de ARPA y el traspaso a DCA

La cadena institucional comenzó con un programa federal de investigación, no con la Internet más amplia.

ARPANET era una red específica de conmutación de paquetes establecida por la Agencia de Proyectos de Investigación Avanzada (Advanced Research Projects Agency) dentro del Departamento de Defensa de los Estados Unidos. ARPA financió el programa de investigación, seleccionó contratistas y apoyó a los centros de investigación participantes. La agencia se convirtió en la Agencia de Proyectos de Investigación Avanzada de Defensa (Defense Advanced Research Projects Agency) en 1972. Por tanto, “ARPA” es apropiado para el establecimiento de la red y el debate temprano sobre nombres, mientras que “DARPA” aparece en registros del período posterior.

ElInforme de Finalización de ARPANET, preparado en 1978, dice que el Instituto de Investigación de Stanford recibió un contrato para desarrollar y operar un Centro de Información de Red para ARPANET. El trabajo comenzó junto con la implementación de la red en 1969. El informe describe un servicio que mantenía listas de participantes y distribución, archivaba documentos técnicos, proporcionaba información sobre los recursos de los hosts, ofrecía acceso al sistema NLS de SRI y mantenía las especificaciones de los protocolos de ARPANET.

Esto establece una relación patrocinador-contratista. ARPA contrató un servicio de información para la red y la comunidad de investigación que apoyaba. SRI tenía el deber de cumplir con lo que exigiera el contrato, y ARPA tenía el derecho correspondiente al cumplimiento contratado. El informe público no reproduce la declaración de trabajo inicial, las enmiendas, los estándares de aceptación, las sanciones, las cláusulas de datos ni las reglas de decisión sobre nombres de hosts. Por tanto, no puede establecer el contenido legal completo de ese deber.

Los sitios conectados a ARPANET eran institucionalmente diversos. Incluían universidades, institutos de investigación, laboratorios gubernamentales, instalaciones militares y contratistas privados. La diversidad de forma jurídica no convertía a cada sitio en un operador público no afiliado. Muchos participaban a través de patrocinio federal, contratos o relaciones de misión aprobadas. Al mismo tiempo, la ausencia de los instrumentos subyacentes de los sitios impide afirmar que cada organización conectada tuviera una cláusula contractual idéntica que exigiera el cumplimiento de la tabla de hosts.

El relato directo más sólido de la transferencia de ARPA a la Agencia de Comunicaciones de Defensa (Defense Communications Agency) está escalonado y fechado. El Informe de Finalización describe un memorando ARPA-DCA según el cual la gestión de ARPANET se transfirió a DCA el 1 de julio de 1975. También registra un período de transición de seis meses, hasta el 31 de diciembre de 1975, durante el cual ARPA continuó asistiendo a DCA mientras esta asumía el papel de gestión. Para junio se había completado un plan de transición detallado.

El informe dice que la red transferida debía operar como una instalación del Departamento de Defensa utilizada para asuntos gubernamentales. DCA financiaría la operación y el mantenimiento mediante un acuerdo de asignación de costos que implicaba a los patrocinadores de ARPANET. Inicialmente, DCA contrataría a BBN y SRI para la operación de la red, el mantenimiento y las funciones del NIC. El informe afirma que estaba claramente implícito que DCA podría retener a otros contratistas más adelante, ciertamente después del primer año.

Eso es evidencia de reemplazabilidad institucional a nivel de selección de contratista. No prueba que DCA poseyera una copia portátil completa de cada registro del NIC, derechos ilimitados sobre los datos creados por el contratista, un paquete de transición probado o un recurso exigible para cada fallo del servicio. Un cliente puede, en principio, poder seleccionar otro proveedor mientras enfrenta obstáculos prácticos formidables para transferir el conocimiento del personal, el software, los archivos, los registros actuales y las relaciones con los sitios.

Una publicación de DCA de 1978 indexada como elFolleto Informativo de ARPANETtambién da el 1 de julio de 1975 como fecha de transferencia de gestión. El instrumento de descripción posterior del Computer History Museum presenta un relato retrospectivo contradictorio: dice que la operación de ARPANET se entregó a DCA en 1973 y que la financiación del contrato de DCA apoyó al NIC de SRI después de 1974.

El conflicto debe permanecer visible. La cronología formal del memorando en el Informe de Finalización proporciona una fecha de transferencia precisa y una transición escalonada. El instrumento de descripción proporciona fechas resumidas diferentes pero no el instrumento subyacente que las reconciliaría. También dice que el NIC se convirtió en un proyecto separado en 1973, lo que es un cambio institucional diferente de la transferencia de la gestión de ARPANET. Sin los contratos y registros administrativos pertinentes, la afirmación operativa de 1973 y la afirmación de financiación posterior a 1974 no pueden convertirse en una única cronología uniforme.

Después de la transferencia formal, DARPA podía seguir patrocinando investigaciones que utilizaran ARPANET mientras DCA gestionaba la red operativa. El Departamento de Defensa era el entorno gubernamental matriz; DARPA y DCA tenían funciones diferentes dentro de él. SRI seguía siendo un contratista que realizaba servicios de NIC, no convertido en el propio gobierno. Los sitios participantes operaban hosts. Los enlaces de host y los roles de contacto posteriores transmitían información e instrucciones. Mantener esos roles distintos evita que la autoridad de contratación se confunda con autoridad universal.

La admisión en ARPANET no era una decisión de la tabla de hosts

La tabla de hosts registraba máquinas dentro de un entorno operativo, pero el mantenimiento del registro por parte de SRI no convertía a SRI en la única autoridad que decidía quién podía unirse a ARPANET.

ElDirectorio ARPANET de diciembre de 1978describía las categorías de suscriptores y el proceso para obtener el servicio. Su marco situaba la admisión y el patrocinio dentro de la estructura de gestión de red de DCA. Un suscriptor potencial necesitaba un propósito gubernamental aceptable, patrocinio y facilidades disponibles. Esas decisiones concernían al acceso a una red gestionada específica.

La distinción es fundamental. DCA podía administrar la elegibilidad de los suscriptores de ARPANET. SRI podía mantener el directorio y la información de los hosts utilizada después o durante la admisión. Una entrada en la tabla de hosts podía ser necesaria para un uso compartido conveniente, pero registrar el host no era el mismo acto institucional que aprobar la conexión de la organización, instalar un Procesador de Mensajes de Interfaz, proporcionar un circuito o autorizar una misión.

La población de ARPANET tampoco debe equipararse a la Internet del Departamento de Defensa. ARPANET era una red. La Internet del DoD era un entorno de interconexión de redes en el que ARPANET, sistemas de radio por paquetes, sistemas satelitales y otras redes podían utilizar los protocolos de Internet y la información de coordinación común. La Internet emergente más amplia era aún más amplia: un conjunto cambiante de redes, experimentos y operadores cuyas relaciones legales, contractuales y técnicas no eran uniformes.

En septiembre de 1981,RFC 790enumeraba los números de red de Internet asignados para numerosas redes nombradas, incluyendo ARPANET, UCLNET, CYCLADES, TELENET, el EPSS de la Oficina de Correos Británica, DATAPAC, TRANSPAC, LCSNET, TYMNET y una variedad de sistemas de radio por paquetes, satelitales, locales y experimentales. Identificaba a Jon Postel en el Instituto de Ciencias de la Información de la Universidad del Sur de California como el contacto para las asignaciones de números de red.

La lista prueba que el entorno de números asignados se extendía más allá de una lista de hosts de ARPANET. Por sí misma, no establece que cada red nombrada estuviera interconectada operativamente en ese momento, independientemente del patrocinio gubernamental, fuera comercial, no perteneciente al DoD o gobernada por el proceso de la tabla de hosts de SRI. Un número que aparece en un documento de asignación no es un relato completo del estatus contractual de la red o de su tráfico real.

También separa funciones que las historias posteriores a veces difuminan. El rol de asignación de números de Postel en USC-ISI concernía a los parámetros de red y protocolo. SRI mantenía la tabla de hosts y el servicio de nombres. DCA gestionaba ARPANET y encargaba el servicio NIC. DARPA continuaba el patrocinio de investigación. Ninguno de esos hechos convierte a un actor en el único autor de toda la Internet emergente.

La frase “primer libro mayor de Internet” necesita, por tanto, una comparación definida. La tabla de hosts no fue el primer directorio mantenido por una organización informática, ni el archivo de 1974 fue un registro para una Internet pública mundial. Fue una referencia temprana de nombre y dirección compartida y legible por máquina en la línea que va de ARPANET a Internet. Para 1982, su formato sucesor incorporaba redes, pasarelas y direcciones de Internet, y sus operadores lo describían como una base de datos global de nombres y direcciones de hosts. Su importancia histórica reside en el alcance cada vez mayor y la dependencia interorganizacional de esa referencia, no en un mandato probado sobre todas las redes.

La norma del DoD de 1982: un requisito previo publicado, no una aplicación probada

El RFC 810 marcó un cambio en el alcance y el lenguaje institucional. Emitido el 1 de marzo de 1982 por Feinler, Ken Harrenstien, Zaw-Sing Su y Vic White del Centro de Información de Red de SRI International, afirmaba que la tabla de hosts anterior de ARPANET ya no satisfacía las necesidades de la comunidad del DoD ni de la interconexión de redes. El nuevo formato incluía entradas de red, pasarela y host, direcciones de Internet, sistemas operativos e información de protocolo.

La tabla estaba disponible desde el hostSRI-NICa través de FTP y mediante el Servidor de Nombres de Host. El RFC identificaba el servidor como un servicio mantenido por el NIC de ARPANET en nombre de DCA. También asignaba expresamente la responsabilidad de la traducción al usuario: quien consumía la tabla debía convertirla al formato requerido localmente.

Su séptima suposición contenía el lenguaje operativo más fuerte en el registro de la tabla de hosts. Los nombres y direcciones de las redes, pasarelas y hosts del DoD debían negociarse y registrarse con el NIC antes de ser utilizados y antes de que un host del DoD cursara tráfico. Este era un requisito previo publicado que regía el comportamiento de los hosts del DoD. Conectaba el registro con la operación de manera más directa que la recomendación de 1974 de utilizar nombres oficiales de hosts.

La frase no documenta la aplicación. El RFC 810 no identifica un monitor que inspeccionara los registros, una regla de enrutador que rechazara el tráfico no registrado, una sanción por incumplimiento, una tasa de cumplimiento o una comunicación particular que fuera bloqueada. La diferencia importa. Una especificación puede definir la conducta requerida sin probar con qué consistencia la implementaron los operadores.

El documento trataba la información no perteneciente al DoD de manera diferente. Durante un período interino, el NIC intentaría mantener información similar para redes y hosts no pertenecientes al DoD si esa información era proporcionada y mientras fuera necesaria, a la espera de servidores de nombres que se intercomunicaran. No identificaba cada entrada no-DoD realmente incluida ni imponía el mismo requisito previo expreso a todos los operadores externos.

El nuevo formato también tuvo una introducción escalonada. El RFC 810 especificaba el 1 de mayo de 1982 como la fecha de corte. Durante mayo, la ruta existenteHOSTS.TXTtodavía contenía la edición antigua mientras que un archivo de prueba del nuevo formato estaba disponible por separado. Durante junio y julio, la ruta principal contenía el nuevo formato, mientras que el material en formato antiguo seguía siendo accesible a través de otra ruta. Después del 1 de agosto, el formato antiguo deHOSTS.TXTespecificado por el RFC 608 dejaría de ser soportado.

Esa superposición distinguía un diseño publicado de una implementación universal inmediata. Los programas tenían tiempo para adaptarse. Los sistemas locales podían permanecer en ediciones diferentes durante la transición. El calendario muestra una gestión activa del riesgo de compatibilidad, pero no prueba que cada host completara la conversión a tiempo.

RFC 811, emitido el mismo día, especificaba el Servidor de Nombres de Host en línea. Un programa podía consultar por un nombre o dirección de host o solicitar toda la tabla. El servidor podía devolver registros de host, pasarela o red. Si un nombre solicitado estaba ausente, el error definido tomaba la formaERR: NAMNFD: Name not found:. Otros errores eran posibles, incluyendoTMPSYS, que significaba un fallo temporal del sistema y una solicitud de intentarlo más tarde.

Esas semánticas pertenecen al protocolo del servidor SRI-NIC. No deben proyectarse sobre cada resolvedor local que utilice una copia descargada. Una búsqueda local contra una tabla que carece de una entrada podía fallar, utilizar un mapeo suplementario, preguntar al usuario o comportarse de otra manera dependiente del sistema. La ausencia de un nombre en una copia local y una respuestaNAMNFDdel servidor eran condiciones relacionadas, no necesariamente eventos idénticos.

El RFC 811 describía su base de datos como una extensión del antiguo archivoHOSTS.TXTde ARPANET y calificaba la administración central como una solución interina en el camino hacia un servicio de traducción de nombres y direcciones descentralizado y distribuido. Esa afirmación institucional es importante por dos razones. Muestra que SRI entendía el servicio como un mecanismo de transición en lugar de una arquitectura permanente, y confirma que la población y el propósito de la tabla se habían expandido más allá de la lista original de ARPANET. No prueba de forma independiente una cobertura universal.

A principios de los años 80, el NIC estaba cada vez más asociado con el entorno de la Red de Datos de Defensa (Defense Data Network), y las colecciones históricas posteriores utilizan el nombre DDN-NIC para el servicio. Esa etiqueta posterior no debe trasladarse hacia atrás al contrato de 1969 o al debate sobre nombres de hosts de 1971. SRI-ARC, el NIC de SRI, SRI-NIC y DDN-NIC describen contextos organizativos y de host conectados pero temporalmente distintos.

Lo que el archivo puede mostrar, y lo que sigue faltando

La serie de RFC es inusualmente rica en propuestas, especificaciones y anuncios. Es mucho más débil como registro de casos administrativos individuales.

El instrumento de descripción del Computer History Museum identifica colecciones relevantes: propuestas y contratos del NIC, informes de progreso, registros de nombres y direcciones, tablas de hosts, material de servicio de referencia, correspondencia y registros relativos a los contactos oficiales de la red. Dice que el contrato inicial del NIC no estaba desglosado en tareas y que los contratos posteriores se volvieron más elaborados. También describe enlaces técnicos, Administradores de Host, Coordinadores de Sitio de Nodo y otros contactos a través de los cuales se movían los mensajes de información o acción.

Un instrumento de descripción establece la existencia, el tema aproximado y la disposición de los registros. No revela el contenido de cada contrato, carta o decisión. Sus descripciones no pueden probar que una solicitud de nombre de host fuera concedida, rechazada o escalada de una manera particular. Los documentos subyacentes tendrían que ser abiertos y comparados.

No se ha presentado aquí ningún archivo de solicitud completo que muestre el nombre propuesto de un host, las preguntas del NIC, la respuesta del sitio y la disposición final. Ningún caso preservado demuestra un rechazo del NIC basado en duplicación, una apelación exitosa, una anulación por parte del patrocinador o un recurso de corrección. Ningún registro completo proporciona tiempos de procesamiento o tasas de error. Los detalles de contacto del RFC 627 prueban que existía un canal de corrección; no prueban los resultados obtenidos a través de él.

Los contratos faltantes importan por una razón separada. Un contrato federal puede conferir un derecho a la prestación sin conferir la propiedad de cada registro, el título de un sistema técnico o derechos ilimitados sobre los datos creados por el contratista. Puede especificar entregables, licencias de datos, asistencia para la transición y recursos, pero esas consecuencias dependen de sus cláusulas reales.

Unanálisis mucho posterior de la Oficina de Responsabilidad Gubernamental sobre los acuerdos de funciones de Internet federalesdistinguió cuidadosamente los derechos de ejecución, los derechos de uso de datos, el título y la propiedad. Esa opinión de 2016 concernía a acuerdos posteriores sobre DNS e IANA y no proporciona los términos faltantes de los contratos de SRI de los años 70. Su valor aquí es metodológico. La financiación federal por sí sola no puede utilizarse para inferir todo derecho de propiedad o de transición.

El Informe de Finalización sí apoya una conclusión más limitada: DCA inicialmente tenía la intención de retener a SRI para la función del NIC y podría utilizar posteriormente a otro contratista. Eso muestra una reemplazabilidad contemplada del proveedor. No establece que el reemplazo pudiera ocurrir sin demora, disputas sobre datos, conversión de software, pérdida de memoria institucional o interrupción del servicio.

También faltan registros de implementación para la condición de tráfico del RFC 810. Para pasar de la regla publicada a la aplicación demostrada, se querrían directivas de DCA, software de host, registros de auditoría, informes de incidentes, sanciones o un flujo bloqueado documentado. Sin ese material, el artículo puede identificar el alcance declarado de la regla pero no su fuerza observada.

El silencio debe operar en ambas direcciones. La falta de un procedimiento de apelación publicado no prueba que no existiera una escalada informal. Las llamadas telefónicas, el correo de red, los intercambios NLS y la intervención del patrocinador pueden haber resuelto disputas sin un RFC. A la inversa, la falta de quejas publicadas no prueba que cada participante considerara legítimo el proceso o que cada actualización fuera oportuna.

La incertidumbre resultante es institucional, no meramente anticuaria. Si las solicitudes se corregían rutinariamente mediante confirmación transparente del sitio, el servicio parecería más administrativo y cooperativo. Si el NIC podía rechazar entradas sin explicación y no existía revisión del patrocinador, el mismo archivo tendría un significado de gobernanza diferente. La evidencia pública no apoya ninguno de los extremos como relato general.

La alternativa de la lista local y sus costos reales

Una alternativa históricamente factible al archivo común no era el moderno Sistema de Nombres de Dominio. Era la práctica ya visible antes del RFC 606: cada sitio mantenía sus propios mapeos, obtenía cambios a través de la comunicación personal y traducía la información remota a su propio sistema operativo.

En cuatro sitios, esto podía ser manejable. Los administradores se conocían entre sí, los diseñadores de protocolos se reunían regularmente, y una corrección podía viajar por teléfono, documento o correo de red. Un sitio podía adoptar un alias local sin esperar una publicación central. Si dos organizaciones se comunicaban con frecuencia, podían mantener su información compartida actualizada incluso cuando una máquina central no estuviera disponible.

La carga de mantenimiento crecía rápidamente. Con diez sitios, cada uno manteniendo entradas para los otros nueve, podía haber hasta 90 mapeos locales dirigidos. Con cien sitios, podía haber hasta 9.900. Estas cifras describen copias dirigidas mantenidas en los sitios, no 90 o 9.900 relaciones bilaterales distintas. El número de mapeos realmente necesarios dependería de los patrones de comunicación, pero cada nuevo destino creaba más lugares en los que la información podía volverse obsoleta.

Una adición de host o cambio de dirección tendría que llegar a múltiples administradores. Cada uno lo aplicaría en un calendario separado y en un formato local. Una corrección podía ser reconocida por un sitio, omitida por otro y transformada incorrectamente por un tercero. Los operadores necesitarían identificar qué edición tenían, comparar informes contradictorios y determinar si un aparente fallo de servicio provenía de la red, el host remoto o un mapeo obsoleto.

El RFC 606 proporciona la advertencia observada: los cuatro sistemas TENEX nombrados ya tenían tablas incompletas y divergentes. No cuantifica los fallos causados por esas diferencias. La propia divergencia demuestra mantenimiento duplicado y respuestas inconsistentes.

Una fuente común reducía esa carga. El host afectado podía comunicar la información a través de un canal reconocido. SRI podía generar una edición. Los sitios podían obtener el mismo archivo y comparar su estado local con una referencia fechada. Un operador de soporte que investigara una discrepancia tenía un punto focal desde el que empezar.

El archivo común no eliminaba todos los costos de distribución. Cada sitio seguía requiriendo almacenamiento, software de recuperación, conversión local y una rutina de actualización. La publicación semanal introducía un retraso entre un cambio notificado y su aparición en la siguiente edición. La obtención podía fallar cuando el host servidor o una ruta de red no estaban disponibles. La instalación local podía retrasarse tras una recuperación exitosa. La arquitectura centralizaba la compilación, no todas las tareas operativas.

Tampoco una fuente común garantizaba la verdad. SRI dependía de los hosts y los contactos para proporcionar información precisa. Una dirección incorrecta suministrada por un sitio podía entrar en el maestro. Una actualización central correcta podía verse socavada por un despliegue local obsoleto. Un conflicto podía persistir si el procedimiento para decidirlo no estaba claro. La referencia hacía visible el desacuerdo y reducía la duplicación, pero no abolía la necesidad de verificación.

La alternativa de la lista local explica por qué las organizaciones deferían al archivo del NIC sin requerir una teoría de mando ilimitado. Una respuesta mantenida era más barata de consumir que muchas reconstruidas independientemente. El software y la documentación se volvían más fiables cuando utilizaban nombres comunes. La dependencia resultante daba al registro mantenido fuerza operativa.

Un libro mayor común con más de un distribuidor

Una segunda alternativa factible en la época habría preservado un archivo canónico mientras distribuía el almacenamiento y la recuperación de manera más amplia.

La idea apareció en documentos contemporáneos.RFC 623proponía que el NIC retuviera el maestro mientras otro host mantenía una copia secundaria actualizada con frecuencia. Su autor se ofrecía voluntario de la UCSB y sugería sincronización diaria. El propósito era la disponibilidad: si el host del NIC no podía servir el archivo, los usuarios podían recurrir al secundario.

RFC 625aceptaba el principio de que más de un host debía mantener una copia y daba la bienvenida a UCSB como un secundario prospectivo. Discrepaba de reemplazar FTP por un protocolo de recuperación dedicado. El RFC 627, emitido más tarde en marzo, todavía invitaba a cualquier host que deseara mantener una copia secundaria a ponerse en contacto con el NIC.

Estos registros establecen un diseño de replicación propuesto y aceptado. No prueban que UCSB u otro host operara un espejo funcional. La confirmación requeriría un aviso operativo, registro del servidor, archivo secundario archivado, manual del host o informe posterior. La propuesta no debe reescribirse como despliegue.

Si tal secundario hubiera operado, habría requerido recursos apropiados para la época. El sitio necesitaba almacenamiento para el archivo, personal o procedimientos automatizados para recuperar actualizaciones, y un calendario lo suficientemente frecuente como para mantener útil su edición. Los usuarios necesitaban saber a qué host contactar y cómo reconocer la última versión canónica. El secundario necesitaba una regla para saber qué hacer cuando su copia local difería de la de SRI.

Una interrupción podía dificultar la reconciliación. Supongamos que el secundario se perdía dos actualizaciones mientras SRI permanecía disponible, y luego regresaba con una edición más antigua. Se necesitaría una convención de marca de tiempo o secuencia para evitar que los usuarios confundieran disponibilidad con actualidad. Si SRI no estaba disponible mientras llegaba una corrección disputada, el secundario necesitaría saber si podía publicar el cambio o simplemente continuar sirviendo el último maestro confirmado.

La replicación también dejaba sin resolver la autoridad de enmienda. Un espejo podía distribuir el archivo canónico sin decidir las entradas. Darle poder de edición independiente crearía la posibilidad de maestros competidores. Evitar ese problema requería una división clara entre la organización que certificaba sus hechos, el centro que reconciliaba el espacio de nombres compartido, el distribuidor que servía copias y cualquier revisor que manejara disputas.

La confirmación del sitio podría haberse fortalecido sin infraestructura moderna. Antes de la publicación semanal, el NIC podría haber enviado un cambio propuesto al enlace afectado o al contacto autorizado del sitio. Un aviso de cambio fechado podría haber acompañado al archivo generado. Los guardianes secundarios podían comparar los cambios anunciados con el archivo que recibían. Los sitios podían informar de discrepancias contra una edición específica en lugar de una copia local sin fecha.

Esos procedimientos habrían impuesto costos. Los contactos tenían que responder. Las correcciones podían esperar confirmación. El personal tenía que mantener registros y conciliar las solicitudes no respondidas. Un host que cambiaba rápidamente podía encontrar un ciclo semanal demasiado lento, mientras que una distribución más frecuente aumentaba la computación, el uso de la red y la carga de trabajo del operador. La revisión formal podía mejorar la rendición de cuentas al tiempo que retrasaba las correcciones urgentes.

La transición de contratista presentaba un problema mayor. La capacidad de DCA para seleccionar otro proveedor no garantizaba el reemplazo sin problemas de SRI. Un sucesor necesitaba el archivo canónico actual, el software que lo generaba, la documentación de los formatos y calendarios de publicación, las solicitudes abiertas, el historial de correcciones, las listas de contactos, el conocimiento del personal y el acceso al entorno de servicio. Si el contrato no especificaba la entrega o los derechos de uso de datos, la transferencia podía volverse legal y operativamente difícil.

Los documentos públicos supervivientes no establecen si esos materiales de transición existían como entregables exigibles. Muestran que se contempló un contratista diferente, no que existiera un mecanismo de transferencia probado. La reemplazabilidad sobre el papel y la continuidad en la operación eran logros separados.

Esta alternativa aclara la elección de gobernanza. Una única respuesta lógica no requería un único distribuidor físico. Una edición canónica podía coexistir con espejos, confirmación del sitio, cambios preservados y un proveedor de servicios de reemplazo. Cada adición habría desplazado costos y responsabilidades sin eliminar la necesidad de coordinación final.

Una cadena de autoridad fechada, no un mandato universal

Entre 1969 y 1983, la autoridad de la tabla de hosts se acumuló a través de una serie de relaciones diferentes.

En 1969, ARPA contrató un Centro de Información de Red para ARPANET. Eso estableció un cliente federal, un contratista SRI y una población de servicio definida. No convirtió a SRI en el representante de cada red informática.

En 1971, se invitó a los hosts a elegir nombres a través de enlaces dentro de las convenciones publicadas. El debate y la respuesta entre los participantes de ARPANET proporcionaron una aceptación limitada entre pares. El papel propuesto del NIC fue restringido por la elección local, mientras que el espacio de nombres compartido aún requería resultados compatibles.

En 1973 y principios de 1974, las tablas locales divergentes impulsaron un archivo común legible por máquina. Los RFC 606 y 608 documentaron la propuesta y el diseño de la fuente. Los RFC 620 y 627 documentaron una instrucción específica de cambio a nivel de sitio, el archivo ASCII disponible, las actualizaciones semanales, la responsabilidad de recuperación local y los canales de corrección. No documentaron un veto general del NIC ni un sistema completo de disputas.

El 1 de julio de 1975, según el memorando ARPA-DCA descrito en el Informe de Finalización, la gestión de ARPANET se transfirió a DCA, seguida de una transición hasta el 31 de diciembre. DCA retuvo inicialmente a SRI para las funciones del NIC y podía contemplar otro contratista. La declaración contradictoria del instrumento de descripción sobre la transferencia operativa en 1973 y la cuenta de financiación posterior a 1974 sigue sin resolverse.

Para 1978, el marco de suscriptores de DCA situaba la admisión en ARPANET dentro de la gestión de la red gubernamental, en lugar del mantenimiento de la tabla de hosts de SRI. Esto separó la autoridad para admitir a un suscriptor del servicio que registraba y distribuía la información de los hosts.

Para 1981, el entorno de números asignados enumeraba muchas redes más allá de ARPANET, mientras que la asignación de números de red se identificaba con Postel en USC-ISI. La aparición en esa lista no establecía que cada red compartiera una relación legal u operativa única con DCA o el NIC.

En marzo de 1982, el RFC 810 especificó una tabla de hosts más amplia para la Internet del DoD y publicó el registro previo como condición para los nombres y direcciones utilizados en relación con el tráfico cursado por los hosts del DoD. Su tratamiento interino separado de la información no-DoD marcó una frontera. La regla era explícita; su aplicación sigue sin probarse. El corte de mayo a agosto mostró además que la especificación, la transición y la implementación local completada eran etapas diferentes.

El servidor del RFC 811 hacía que la respuesta mantenida estuviera disponible a través de consultas en línea y describía la base de datos central como un puente interino hacia la denominación distribuida. Ese servicio aumentó la dependencia de SRI-NIC al tiempo que reconocía que la arquitectura no estaba destinada a permanecer permanentemente centralizada.

Por tanto, la tabla de hosts ejerció su autoridad demostrada más fuerte en tres lugares. SRI debía rendimiento a su cliente federal dentro del alcance de un contrato cuyos términos completos no están disponibles. DCA podía emitir requisitos operativos para el entorno del DoD que gestionaba. Las máquinas y usuarios participantes dependían del registro común para una comunicación coherente basada en nombres.

Fuera de esas relaciones, el alcance de la tabla surgía de la interoperabilidad y la adopción. Una red externa podía contribuir con información o utilizar el archivo común porque hacerlo facilitaba la comunicación. Esa dependencia era relevante, pero el RFC 810 no la describía como equivalente al requisito previo del DoD. Ningún registro revisado muestra a un electorado mundial que delegara autoridad general en SRI.

La tabla tampoco creaba todo lo que registraba. El patrocinador aprobaba la participación en la red; los contratistas y los sitios suministraban máquinas y software; los circuitos y conmutadores de paquetes transportaban el tráfico; otras autoridades manejaban los números de red; los sistemas locales consumían los mapeos publicados. El registro del NIC ayudaba a que un nombre fuera comúnmente reconocible, pero no creaba la organización subyacente, la conexión física ni todas las asignaciones numéricas.

No obstante, su autoridad práctica era sustancial. Un registro compartido consumido por muchas máquinas puede restringir la conducta incluso cuando ninguna legislatura u organismo público de miembros lo creó. Un host que quería un reconocimiento predecible tenía razones para seguir las convenciones de nombres. Un sitio que quería respuestas actuales tenía razones para recuperar el archivo común. Un host del DoD estaba sujeto a un requisito previo de registro publicado. Un operador no perteneciente al DoD podía encontrar costosa la desviación porque otros sistemas esperaban la respuesta mantenida.

Lo que sigue sin probarse es igualmente importante. La evidencia pública superviviente no muestra que el NIC fuera propietario de las direcciones que enumeraba, pudiera excluir a cualquier red externa a voluntad, impusiera sanciones a cada sitio no conforme o convirtiera cada entrada faltante en desconexión física. No revela una estructura de apelación completa, un recurso de corrección o una jerarquía de anulación. No establece la propiedad gubernamental portátil de todos los datos del NIC.

La tabla de hosts temprana era autoritativa allí donde se encontraban la contratación, la gestión de la red y la dependencia de las máquinas. Resolvió un problema concreto: los mapeos locales incompatibles hacían que los nombres compartidos no fueran fiables. La compilación central facilitó la distribución, comparación y uso de una respuesta única. Ese logro explica por qué el registro adquirió fuerza antes de que los nombres y las direcciones se convirtieran en activos de mercado.

No prueba que el operador del registro recibiera autoridad sobre cada red que el registro pudiera describir. La cadena histórica apoya una conclusión más limitada: SRI mantuvo una referencia encargada federalmente para una red patrocinada, esa referencia se integró en las operaciones de la Internet del DoD, y una dependencia más amplia amplió su alcance práctico. La utilidad del libro mayor lo hizo poderoso. Su mandato público seguía sin establecerse.