Resumen

  • RFC 832 tomó del registro del NIC lo que cada host decía ofrecer y lo comparó con intentos reales de Telnet, FTP y SMTP clasificados como no aceptado, rechazado, inalcanzable, sin respuesta o aceptado.
  • Los resultados negativos se repitieron y cada semana apareció una nueva medición. El estado pertenecía a una ruta, un observador y una hora, no a una etiqueta permanente del host.
  • RFC 844 cambió de punto de observación y solo obtuvo éxito con 127 de los 187 servidores Telnet antes aceptados. Medir ejecución daba más evidencia que el padrón, pero no una verdad universal ni mando sobre la máquina.

Una lista de afirmaciones, no de hechos consumados

La tabla de nombres del NIC fechada el 2 de diciembre de 1982 indicaba TCP en general o servicios concretos mediante marcas para Telnet, FTP y SMTP. RFC 832 llamó a esa columna Claims. No era un insulto al registro: era una definición de su alcance.

Al lado puso el nombre, la dirección y tres resultados de conexión. Un host sin marca podía aceptar; otro que declaraba un servicio podía guardar silencio. La comparación no permitía que el registro corrigiera a la red por decreto ni que un ensayo borrara la historia de la entrada.

RFC 801 ayuda a entender por qué hacía falta esa separación. El plan de transición recopilaba estados comunicados por implementadores: disponible, experimental, en desarrollo o previsto. Avisaba que la información podía envejecer deprisa y enumeraba fallos que una implementación no debía ocultar, desde no verificar checksums hasta no reordenar segmentos o ignorar opciones.

Abrir un puerto no demostraba todos esos requisitos. La encuesta eligió una proposición más estrecha: en este intervalo y desde esta máquina, ¿qué ocurre al intentar una conexión al servicio conocido?

El fracaso tenía varias gramáticas

Refused indicaba una respuesta que rechazaba la apertura. Unreachable registraba una señal explícita del camino. Dead nombraba la falta de respuesta útil bajo el método. Una casilla vacía decía que no hubo aceptación sin fingir que se conocía la causa. Accepted marcaba que el umbral de transporte había sido superado.

FTP añadió accepted+ cuando funcionaba el usuario anónimo con contraseña guest. La excepción muestra lo poco que afirmaba la aceptación ordinaria: no probaba login, transferencia, utilidad, identidad ni corrección total de la aplicación.

El 7 de diciembre hubo dos ventanas de ensayo. Los hosts muertos, rechazados o inalcanzables se volvieron a probar el 8. El reintento reducía el riesgo de confundir un instante malo con una condición persistente, pero no convertía la observación en eterna.

De 315 hosts, 83 aceptaron Telnet, 70 FTP y 63 SMTP. Los restantes no eran automáticamente incumplidores. Había máquinas especiales, servicios no expuestos y sistemas apagados. La encuesta medía una superficie, no definía quién merecía pertenecer a Internet.

Cada semana revocaba la fotografía anterior

RFC 833 repitió el trabajo el 14 de diciembre y dejó constancia de un cambio aparentemente menor: los hosts duplicados se eliminaron de forma algo distinta, por lo que los totales variaron. Así se impidió atribuir al despliegue lo que pertenecía al tratamiento de datos.

RFC 847 reunió doce encuestas. Entre el 7 de diciembre y el 22 de febrero, las aceptaciones de Telnet subieron de 83 a 190; FTP, de 70 a 181; SMTP, de 63 a 178. La transición se volvía visible en máquinas que respondían.

Sin embargo, hubo descensos. Telnet marcó 103, luego 102 y después 95 en tres semanas de diciembre. El padrón cambiaba, las rutas fallaban, los horarios eran distintos y los operadores abrían o cerraban servicios. Una serie operativa no era una barra de avance administrada.

La última medición, RFC 846, volvió a declarar todos sus ejes: tabla del 18 de febrero, pruebas del 22 desde ISI-VAXA y repetición de negativos el 23. No proclamó que TCP hubiera ganado para siempre. Entregó otra evidencia fechada.

Mover la sonda cambió lo que significaba “aceptado”

RFC 843 había contado 187 hosts con Telnet aceptado desde ISI-VAXA los días 8 y 9 de febrero. RFC 844 tomó ese conjunto y lo probó desde un concentrador de terminales de BBN situado en la red de clase C 192.1.2.0/24.

La segunda prueba exigía que el camino conociera esa red, que los hosts manejaran la clase de dirección y que ICMP y el enrutamiento cooperaran. Solo 127 de los 187 aparecieron como OK: 67,9 por ciento.

No era una refutación absoluta de la primera encuesta. RFC 844 reconoció que los intentos fueron manuales, que solo se hicieron tres pasadas y que algunos hosts podían estar apagados. Los sesenta restantes no perdieron TCP por haber sido observados desde BBN.

Las proposiciones eran distintas. ISI había observado aceptación en su contexto. BBN examinó alcanzabilidad desde otra clase de red y otro recorrido. La infraestructura oculta se hizo visible al mover al observador.

La síntesis también dejó huellas de error

RFC 847 estimó que 37 hosts, un 11 por ciento, eran de propósito especial y no debían ofrecer los tres servicios. Por eso propuso 89 por ciento como máximo razonable. La ausencia de Telnet no equivalía a ausencia de Internet.

El cuadro agregado, además, conserva anomalías. Presenta 70 de 315 como 26 por ciento, aunque ronda el 22; imprime 382 donde los totales vecinos indican 328, 389 donde la población era 329 y fecha en 1982 una observación de febrero de 1983.

La lección no es descartar la fuente. Es conservar numerador, denominador, método y encuesta original. Una cifra derivada puede recalcularse si la cadena permanece. Sin ella, la pulcritud solo oculta el error.

La sonda no adquirió jurisdicción

El equipo de medición escogía puertos, horas y vocabulario. El operador remoto decidía qué software ejecutar y qué servicio exponer. Una conexión aceptada no autorizaba acciones sobre el host; un timeout no transfería propiedad ni demostraba mala conducta.

La ejecución podía corregir una declaración porque era comprobable. Su autoridad terminaba en la proposición comprobada. Un socket abierto no certificaba todo TCP, no autenticaba al responsable, no prometía una transacción útil y no describía todos los caminos.

RFC 832 dejó una arquitectura de conocimiento mejor que un semáforo: declaración, experimento, resultado tipado, reintento y siguiente edición. La red tenía permiso para responder algo más complejo que sí o no.

Fuentes y límites de la evidencia

Estas RFC documentan planes, declaraciones fechadas, intentos de conexión y un resumen. No prueban despliegue actual, conformidad completa, identidad, autorización ni finalización de una operación. Todo resultado negativo conserva los límites de lugar, camino, método y tiempo declarados.