Dominio principal
Infraestructura de Internet
En la faceta Dominio principal, los análisis de Infraestructura de Internet se agrupan por dominio principal para que los lectores puedan seguir un área concreta de la infraestructura de Internet, la gobernanza, los mercados de conectividad o el capital digital. La página reúne artículos relacionados, evidencia pública, instituciones, empresas, personas, exposición regional, dependencias operativas y contexto de mercado que de otro modo aparecerían en páginas de categoría separadas. Explica el dominio, la clase probable de actor, el contexto de mercado o de gobernanza y el material de origen que los lectores deben usar al comparar señales. Operadores, analistas y lectores de gobernanza pueden ver cómo el mismo dominio aparece en eventos, perfiles, cambios de mercado, evidencia de fuentes públicas, dependencias regionales y decisiones de infraestructura de ciclos más largos a lo largo del tiempo.
Historia de Internet
La tecla atravesó dos sesiones: cómo RFC 818 convirtió al cliente Telnet en servicio
El operador pulsaba una tecla y veía un solo terminal. La tecla, sin embargo, terminaba una conexión Telnet, cruzaba un pseudo-terminal dentro de un concentrador y entraba en otra conexión iniciada por un segundo programa. RFC 818 hizo accesible ese montaje en el puerto 107. Su…
Historia de Internet
El servicio de nombres casi fue un negociador: cómo RFC 830 separó dominios y capacidades
Una consulta de RFC 830 podía recibir dos respuestas en momentos distintos. La primera conducía al punto de servicio del dominio de destino. La segunda decía si allí existía el transporte y la aplicación solicitados, o proponía una alternativa. Entre ambas quedaba una frontera…
Historia de Internet
El número no lo convertía en estándar: cómo RFC 825 hizo visible la intención del documento
Un informe de política cita una RFC y, al copiarla, pierde una sola palabra: *Informational*. El enlace sigue funcionando y el número sigue siendo exacto, pero la afirmación ha cambiado. Lo que era una publicación para informar empieza a parecer una recomendación técnica. RFC 825…
Tendencias de telecomunicaciones nacionales de Europa y Oriente Medio
El equipo de 5G privada no es una red local hasta que la licencia coincide con el emplazamiento
Las radios instaladas, las SIM activas y un plano de cobertura describen una red proyectada. En el Reino Unido, la aceptación exige además que la autorización final de espectro coincida con lo que realmente se construyó.
Historia de Internet
La capa no era el módulo: cómo RFC 817 atravesó la pila
En Multics, sumar el checksum de un segmento TCP de 576 bytes llegó a consumir unos seis milisegundos. No era porque TCP exigiera seis milisegundos, sino porque bytes de ocho bits caían incómodamente dentro de palabras de 36. Una reescritura muy localizada redujo el tiempo a…
Historia de Internet
El mensaje de error era un consejo, no un veredicto: cómo RFC 816 repartió las decisiones de fallo
El fallo más difícil de denunciar era el de la primera pasarela: al morir, también perdía la capacidad de explicar por qué desaparecían los paquetes. RFC 816 convirtió esa paradoja en una arquitectura de responsabilidades, desde la selección de ruta hasta el acuse final de la…
Historia de Internet
El segmento perdido no detenía al siguiente: cómo RDP separó fiabilidad y orden
Una imagen de memoria puede llegar por piezas. Si falta una, la imagen está incompleta; eso no convierte en inútiles las piezas posteriores que sí llegaron y que saben dónde deben colocarse. El Reliable Data Protocol nació de esa diferencia. Aseguraba que el hueco acabaría…
IETF
Dieter Sibold y el sobre cifrado que viaja con la hora
La palabra cookie sugiere seguimiento o navegación web. En NTS designa otra cosa: un sobre opaco que el servidor entrega al cliente para que lo custodie. Cuando llega la siguiente consulta NTP, el sobre devuelve las claves de la asociación al servidor sin obligarlo a mantener una…
Historia de Internet
El nombre no era la dirección: cómo RFC 814 separó la identidad de la ruta
Un ordenador personal con una sola sesión Telnet no necesitaba conocer todos los destinos de Internet; quizá le bastaba una asociación de ruta. Un sistema compartido podía necesitar cien. RFC 814 partió de esa diferencia para defender algo mayor: el estado local debía crecer con…
Tendencias de ISP regionales de Europa y Oriente Medio
Dos circuitos de fibra no son diversos hasta demostrar sus rutas
Dos accesos pueden tener contratos, identificadores y marcas diferentes y, aun así, caer por la misma excavación. La resiliencia empieza cuando se hacen visibles los dominios de fallo compartidos, no cuando el departamento de compras añade un segundo proveedor.
IETF
David Lawrence y la respuesta DNS que siguió viva tras su TTL
Que una respuesta DNS haya caducado no obliga a fingir que ya no existe, pero tampoco permite tratarla como vigente. RFC 8767 abre un puente de continuidad: el resolvedor intenta llegar a la fuente autoritativa, clasifica el fallo, usa durante poco tiempo la copia antigua y sigue…
Historia de Internet
El acuse que terminaba en el enlace: cómo PPP acotó la fiabilidad
Un acuse de recibo puede cerrar una duda y abrir otras. RFC 1663 permitió a dos vecinos PPP recuperar tramas perdidas con números de secuencia, ventanas y retransmisiones. Pero el significado del acuse terminaba allí: no acreditaba al interlocutor, no garantizaba una ruta y no…
Historia de Internet
La jerarquía era en realidad un grafo: cómo Gopher puso el siguiente servidor en cada línea de menú
Gopher parecía un archivador ordenado, pero cada selección podía abandonar la máquina que mostraba el menú. La línea elegida llevaba dos historias a la vez: una etiqueta amable para la persona y una instrucción precisa para el programa, compuesta por tipo, selector opaco, host y…
IETF
Steve Sheng y el bloqueo que no detuvo el mantenimiento DNSSEC
El panel puede mostrar un dominio bloqueado y, aun así, el padre publicar un DS nuevo de forma legítima. RFC 10026 explica por qué: el bloqueo pertenece a un actor y a una clase de órdenes; no congela por definición todos los caminos de mantenimiento.
Historia de Internet
El informe no podía declarar mala la línea: PPP dejó el umbral en cada extremo
Dos equipos podían observar exactamente los mismos contadores y tomar decisiones distintas. PPP convirtió esa diferencia en una característica deliberada: Link-Quality-Report fijaba cómo comparar lo enviado y lo recibido, pero no decidía cuánta pérdida era tolerable ni quién…
Historia de Internet
Mohamed Awang Lah y JARING: los límites de una autoridad compartida
La historia de una infraestructura nacional suele concentrarse en su dirigente más visible. Sin embargo, la capacidad de diseñar y operar una red no equivale a poseer la institución, controlar a sus accionistas ni decidir su destino judicial. Mohamed Awang Lah tuvo una…
Historia de Internet
Un enlace era en realidad varios: cómo PPP Multilink mantuvo una sola secuencia en el haz
Dos líneas podían comportarse ante la capa de red como una sola conversación. PPP Multilink no ocultó que cada miembro tenía su propio entramado, pero dio a todos los fragmentos un orden común dentro del haz. Así fijó la reconstrucción interoperable sin convertir la elección de…
Historia de Internet
El éxito que invalidaba su propio flujo: por qué XMPP recomenzaba después de TLS y SASL
XMPP podía conservar intacta una conexión TCP y, aun así, declarar que el flujo XML anterior ya no servía. El éxito de TLS o de SASL cambiaba el suelo sobre el que se habían aprendido identidades y capacidades. Por eso la conversación volvía a presentarse: otro encabezado, otro…
Historia de Internet
Los caracteres que la suma de comprobación nunca vio: cómo PPP depuraba el trayecto serie antes de confiar en la trama
Una línea serie podía añadir su propia historia a los bytes que transportaba. PPP no convirtió esa historia en contenido protegido. Primero deshacía el revestimiento reversible de la ruta y retiraba un conjunto negociado de controles que podían proceder del equipo intermedio…
Historia de Internet
La cabecera que solo existía si ahorraba bytes: la condición de IPComp
IPComp no convirtió la compresión en una promesa del túnel. La convirtió en un examen para cada datagrama. Si la carga comprimida y la cabecera de cuatro octetos ocupaban lo mismo o más que la carga original, la única salida válida era el paquete original, sin rastro de IPComp.…