19 dic 2025·8 min
Jon Postel y la cultura práctica tras los estándares de Internet
Cómo la mentalidad práctica de Jon Postel moldeó la gobernanza de Internet, ayudando a que redes interoperen mediante RFCs, normas de la IETF y coordinación temprana.
Cómo la mentalidad práctica de Jon Postel moldeó la gobernanza de Internet, ayudando a que redes interoperen mediante RFCs, normas de la IETF y coordinación temprana.
Las primeras redes de computadoras no fueron “una red que se hizo más grande”. Eran muchas redes separadas: gestionadas por organizaciones distintas, construidas sobre hardware diferente, financiadas con objetivos diversos y diseñadas con supuestos distintos. Algunas eran académicas y colaborativas, otras militares y otras comerciales. Cada red podía funcionar bien por sí misma y aun así ser incapaz (o no estar dispuesta) a comunicarse con las demás.
A grandes rasgos, el reto era simple: ¿cómo conectar redes que no comparten las mismas reglas?
Los formatos de direcciones diferían. Los tamaños de los mensajes diferían. El manejo de errores difería. Incluso expectativas básicas como “¿cuánto tiempo esperamos antes de reintentar?” podían variar. Sin acuerdos compartidos, no tienes una Internet: tienes islas desconectadas con unos pocos puentes a medida.
Esos puentes son caros de construir y fáciles de romper. Además tienden a encerrar a la gente con un proveedor u operador concreto, porque la “capa de traducción” se convierte en un punto de estrangulamiento competitivo.
Es tentador describir las primeras redes como una guerra de protocolos en la que la tecnología “mejor” ganó. En la práctica, la interoperabilidad a menudo importaba más que la elegancia técnica o la dominancia de mercado. Un protocolo algo imperfecto pero ampliamente implementable puede conectar a más gente que uno teóricamente superior que solo funciona dentro de un ecosistema.
El éxito de Internet dependió de una cultura que recompensaba hacer que las cosas funcionaran juntas—entre instituciones y fronteras—incluso cuando ninguna entidad única tenía la autoridad para imponer cooperación.
Jon Postel se convirtió en uno de los administradores más confiables de esta cooperación. No porque tuviera un mandato gubernamental amplio, sino porque ayudó a moldear hábitos y normas que hicieron creíbles los estándares compartidos: escribir con claridad, probar en implementaciones reales y coordinar los detalles aburridos pero esenciales (como nombres y números) para que todos se mantuvieran alineados.
Esto no es una inmersión técnica en formatos de paquetes. Se trata de las prácticas y decisiones de gobernanza prácticas que hicieron posible la interoperabilidad: la cultura de estándares alrededor de los RFC, el estilo de trabajo de la IETF y la coordinación silenciosa que evitó que la red en crecimiento se fragmentara en mini-Internets incompatibles.
Jon Postel no fue un CEO famoso ni un funcionario gubernamental. Fue un ingeniero y editor que pasó gran parte de su carrera en UCLA y luego en el Information Sciences Institute (ISI), donde ayudó a convertir ideas tempranas de redes en práctica compartida y usable.
Si alguna vez has escrito un nombre de dominio, enviado un correo electrónico o confiado en dispositivos de distintos proveedores para que “simplemente funcionen” juntos, te has beneficiado del tipo de coordinación que Postel proporcionó en silencio durante décadas.
Postel fue eficaz porque trató a los estándares como un servicio público: algo que se mantiene para que otros puedan construir. Tenía reputación de claridad al escribir, paciencia en el debate y persistencia para resolver detalles. Esa combinación importaba en una comunidad donde los desacuerdos no eran académicos—podían dividir implementaciones y dejar usuarios varados.
También realizó el trabajo poco glamuroso: editar y curar notas técnicas, responder preguntas, impulsar grupos hacia decisiones y mantener los registros compartidos organizados. Ese servicio constante y visible lo convirtió en un punto de referencia fiable cuando subían los ánimos o se retrasaban los plazos.
Una parte clave de la influencia de Postel fue que no dependía del poder formal. La gente escuchaba porque era coherente, justo y profundamente conocedor—y porque aparecía, una y otra vez, para hacer el trabajo. En otras palabras, poseía “autoridad” como lo hacen los buenos mantenedores: siendo útil, predecible y difícil de reemplazar.
La Internet temprana era un mosaico de universidades, laboratorios, contratistas y proveedores con prioridades distintas. La credibilidad de Postel ayudó a que esos grupos cooperaran de todos modos. Cuando alguien confiaba en que una decisión se tomaba por interoperabilidad—no por política o beneficio—estaba más dispuesto a alinear sus sistemas, aun si eso implicaba compromisos.
Un RFC —RFC (Request for Comments)— es un memo público que explica cómo debe funcionar un protocolo o una práctica de Internet. Piénsalo como: “aquí está la idea, aquí el formato, aquí las reglas—dinos qué falla.” Algunos RFC son bocetos tempranos; otros se convierten en estándares ampliamente usados. El hábito central es el mismo: escríbelo para que otros puedan construir desde la misma página.
Los RFC fueron deliberadamente prácticos. Pretendían ser útiles para implementadores, no impresionantes para comités. Eso significó detalles concretos: formatos de mensajes, casos de error, ejemplos y las aclaraciones aburridas pero críticas que evitan que dos equipos interpreten la misma frase de manera opuesta.
Igualmente importante, los RFC se escribían para ser probados y revisados. Publicar no era la línea de meta—era el comienzo de la retroalimentación en el mundo real. Si una idea funcionaba en código pero fallaba entre redes, el documento podía actualizarse o reemplazarse. Este ritmo de “publicar temprano, mejorar abiertamente” mantuvo los protocolos anclados en la práctica.
Cuando las especificaciones son privadas, los malentendidos se multiplican: un proveedor oye una explicación, otro oye otra ligeramente distinta y la interoperabilidad se convierte en una reflexión tardía.
Hacer los RFC públicamente disponibles alineó a todos—investigadores, proveedores, universidades y, más tarde, actores comerciales—en torno a un mismo texto de referencia. Los desacuerdos no desaparecieron, pero se hicieron visibles y, por tanto, solucionables.
Una razón clave por la que los RFC se mantenían legibles y coherentes fue la disciplina editorial. Los editores (incluido Jon Postel durante muchos años) impulsaban la claridad, la terminología estable y una estructura común.
Luego la comunidad en general revisaba, cuestionaba supuestos y corregía casos límite. Esa mezcla—edición rigurosa más crítica abierta—creó documentos que realmente podían implementarse por personas que no estuvieron en la sala original.
“Consenso aproximado y código en ejecución” es la manera de la IETF de decir: no resuelvas discusiones debatiendo lo que podría funcionar—construye algo que funcione, muéstralo y luego escribe lo que aprendiste.
Código en ejecución no es un eslogan sobre amar el software. Es un estándar de prueba:
En la práctica, esto impulsa el trabajo de estándares hacia prototipos, demostraciones de interoperabilidad, suites de pruebas y ciclos repetidos de “pruébalo, arréglalo, vuélvelo a intentar”.
Las redes son desordenadas: la latencia varía, los enlaces caen, las máquinas difieren y la gente construye cosas de formas inesperadas. Al requerir algo ejecutable pronto, la comunidad evitó debates filosóficos interminables sobre el diseño perfecto.
Los beneficios fueron prácticos:
Este enfoque no está exento de riesgos. “Lo primero que funciona gana” puede crear encierros prematuros, donde un diseño temprano se vuelve difícil de cambiar después. También puede premiar a equipos con más recursos, que pueden construir implementaciones antes y así moldear la dirección.
Para evitar que la cultura se convirtiera en “envíalo y olvídalo”, la IETF se apoyó en pruebas e iteración. Eventos de interoperabilidad, múltiples implementaciones y ciclos de revisión cuidadosos ayudaron a separar “funciona en mi máquina” de “funciona para todos”.
Esa es la idea central: estándares como registro de práctica probada, no como lista de deseos de características.
“Fragmentación” aquí no solo significa que existan múltiples redes al mismo tiempo. Significa redes incompatibles que no pueden hablar entre sí con soltura, además de esfuerzos duplicados en los que cada grupo reinventa la misma plomería básica de formas ligeramente distintas.
Si cada red, proveedor o proyecto gubernamental hubiera definido sus propias reglas de direccionamiento, nombres y transporte, conectar sistemas exigiría traducción constante. Esa traducción suele aparecer como:
El resultado no es solo complejidad técnica: son precios más altos, innovación más lenta y menos gente capaz de participar.
Los estándares públicos y compartidos hicieron que Internet fuera más barato de integrar. Una red universitaria nueva, un ISP emergente o un proveedor de hardware no necesitaban permiso especial ni un acuerdo de integración a medida. Podían implementar las especificaciones publicadas y esperar interoperabilidad con los demás.
Esto redujo también el coste de experimentar: podías construir una aplicación nueva sobre protocolos existentes sin negociar un pacto de compatibilidad con cada operador.
Evitar la fragmentación requería más que buenas ideas; requería coordinación que los incentivos competitivos no podían proporcionar fácilmente. Grupos distintos querían resultados distintos—ventaja comercial, prioridades nacionales, objetivos de investigación—pero aun así necesitaban un punto común para identificadores y comportamientos de protocolo.
La coordinación neutral ayudó a mantener compartido el tejido conectivo, incluso cuando las partes que construían encima no se confiaban del todo. Es una gobernanza práctica y silenciosa: no controlar la red, sino evitar que se partiera en islas aisladas.
La IETF no tuvo éxito porque poseyera la mayor autoridad. Lo consiguió porque construyó una forma fiable para que muchas personas y organizaciones independientes acuerden cómo debe comportarse Internet—sin exigir que una sola empresa, gobierno o laboratorio poseyera el resultado.
La IETF opera como un taller público. Cualquiera puede unirse a listas de correo, leer borradores, asistir a reuniones y comentar. Esa apertura importó porque los problemas de interoperabilidad suelen aparecer en los bordes—donde distintos sistemas se encuentran—y esos bordes pertenecen a mucha gente diferente.
En vez de tratar la retroalimentación externa como una molestia, el proceso la considera un insumo esencial. Si una propuesta rompe redes reales, alguien suele avisarlo rápido.
La mayor parte del trabajo ocurre en grupos de trabajo, cada uno enfocado en un problema específico (por ejemplo, cómo formatear el correo electrónico o cómo intercambiar información de enrutamiento). Un grupo de trabajo se forma cuando hay una necesidad clara, suficientes contribuyentes interesados y una carta que defina el alcance.
El progreso tiende a verse práctico:
La influencia en la IETF se gana asistiendo, haciendo trabajo cuidadoso y respondiendo a críticas—no por cargo. Editores, implementadores, operadores y revisores todos dan forma al resultado. Eso crea una presión útil: si quieres que tu idea se adopte, debes hacerla comprensible e implementable.
El debate abierto puede convertirse fácilmente en discusión interminable. La IETF desarrolló normas que mantenían las conversaciones enfocadas:
La “victoria” no es retórica. La victoria es que sistemas construidos de forma independiente sigan funcionando juntos.
Cuando la gente habla de cómo funciona Internet, suele imaginar grandes inventos: TCP/IP, DNS o la web. Pero mucha interoperabilidad depende de algo menos glamuroso: acordar listas maestras comunes. Ese es el trabajo básico de IANA—la Internet Assigned Numbers Authority.
IANA es una función de coordinación que mantiene registros compartidos para que distintos sistemas puedan alinear sus ajustes. Si dos equipos independientes construyen software a partir del mismo estándar, esos estándares aún necesitan valores concretos—números, nombres y etiquetas—para que sus implementaciones coincidan en el mundo real.
Algunos ejemplos para hacerlo tangible:
Sin un registro compartido, ocurren colisiones. Dos grupos podrían asignar el mismo número a características distintas o usar etiquetas distintas para el mismo concepto. El resultado no es un fallo dramático: es peor—errores intermitentes, incompatibilidades confusas y productos que solo funcionan dentro de su propio burbuja.
El trabajo de IANA es “aburrido” en el mejor sentido. Convierte el acuerdo abstracto en consistencia cotidiana. Esa coordinación silenciosa permite que los estándares viajen—entre proveedores, países y décadas—sin renegociación constante.
A Jon Postel se le suele asociar una regla práctica que moldeó el comportamiento del software de Internet temprano: "sé estricto con lo que envías, flexible con lo que aceptas". Suena a directriz técnica, pero también actuó como un contrato social entre desconocidos que debían hacer que sus sistemas funcionaran juntos.
“Estricto con lo que envías” significa que tu software debe seguir la especificación de forma rigurosa al producir datos—sin atajos creativos ni “todos saben lo que quise decir”. El objetivo es evitar propagar interpretaciones extrañas que otros tengan que copiar.
“Flexible con lo que aceptas” implica que cuando recibes datos que están algo fuera de norma—tal vez un campo faltante, formato inusual o un comportamiento límite—debes intentar manejarlo con gracia en lugar de bloquearte o rechazar la conexión.
En la Internet inicial, las implementaciones eran desiguales: máquinas distintas, lenguajes de programación distintos y especificaciones incompletas que se refinaban en tiempo real. La flexibilidad permitió que los sistemas se comunicaran aun cuando ninguna de las dos partes fuera perfecta.
Esa tolerancia compró tiempo para que el proceso de estándares convergiera. También redujo la presión de bifurcación—los equipos no necesitaban su propia variante incompatible solo para hacer algo funcionar.
Con el tiempo, ser demasiado flexible creó problemas. Si una implementación acepta entrada ambigua o inválida, otras pueden depender de ese comportamiento y convertir errores en “características”. Peor aún, el análisis liberal puede abrir problemas de seguridad (piensa en ataques por inyección o en saltos creados por interpretaciones inconsistentes).
La lección actualizada es: maximiza la interoperabilidad, pero no normalices entradas malformadas. Sé estricto por defecto, documenta excepciones y trata los datos “aceptados pero no conformes” como algo para registrar, limitar y eliminar con el tiempo—compatibilidad con seguridad en mente.
Las grandes ideas como “interoperabilidad” pueden sonar abstractas hasta que miras los sistemas cotidianos que cooperan cada vez que abres un sitio web o envías un mensaje. TCP/IP, DNS y el correo (SMTP) son un trío útil porque cada uno resolvió un problema de coordinación distinto—y cada uno asumía que los otros existirían.
Las redes tempranas podían haber acabado como islas: cada proveedor o país ejecutando su propia suite de protocolos incompatible. TCP/IP proporcionó una base común sobre “cómo se mueve la información” que no requería que todos compraran el mismo hardware ni ejecutaran el mismo sistema operativo.
La clave no fue que TCP/IP fuera perfecto. Fue suficientemente bueno, especificado abiertamente e implementable por muchas partes. Una vez que suficientes redes lo adoptaron, elegir una pila incompatible significaba elegir aislamiento.
Las direcciones IP son difíciles para las personas y frágiles para los servicios. DNS resolvió el problema de los nombres—convertir nombres legibles en direcciones enrutables.
Pero nombrar no es solo un mapeo técnico. Necesita delegación clara: quién puede crear nombres, quién puede cambiarlos y cómo se previenen conflictos. DNS funcionó porque emparejó un protocolo sencillo con un espacio de nombres coordinado, permitiendo a operadores independientes gestionar sus dominios sin romper al resto.
El correo triunfó porque SMTP se centró en una promesa estrecha: transferir mensajes entre servidores usando un formato común y una conversación predecible.
Ese desacoplamiento importó. Organizaciones distintas podían ejecutar software de correo, sistemas de almacenamiento y políticas de spam diferentes y aun así intercambiar correo. SMTP no imponía un único proveedor ni una única experiencia de usuario—solo estandarizaba la entrega.
Juntos, estos estándares forman una cadena práctica: DNS ayuda a encontrar el destino, TCP/IP lleva los paquetes y SMTP define lo que los servidores de correo se dicen una vez conectados.
“Gobernanza de Internet” puede sonar a tratados y reguladores. En la Internet temprana, muchas veces se parecía más a una corriente continua de llamadas pequeñas y prácticas: qué números reservar, qué significa un campo de protocolo, cómo publicar una corrección o cuándo fusionar dos propuestas. La influencia de Postel vino menos de la autoridad formal y más de ser la persona que mantenía esas decisiones en movimiento—y las documentaba.
No había una “policía de Internet” central. En su lugar, la gobernanza ocurría mediante hábitos que hacían que cooperar fuera el camino más fácil. Cuando surgía una pregunta—por ejemplo, sobre un registro de parámetros o una ambigüedad de protocolo—alguien tenía que elegir una respuesta, escribirla y distribuirla. Postel, y más tarde la función IANA que administró, proporcionaron un punto de coordinación claro. El poder era silencioso: si querías que tu sistema funcionara con los demás, te alineabas con las elecciones compartidas.
La confianza se construyó mediante registros transparentes. Los RFC y las discusiones en listas públicas significaban que las decisiones no estaban ocultas en reuniones privadas. Incluso cuando individuos tomaban decisiones, se esperaba que dejaran rastro: racional, contexto y una forma para que otros impugnen o mejoren.
La rendición de cuentas venía en gran medida de implementadores y pares. Si una decisión provocaba fallos, la retroalimentación era inmediata—el software fallaba, los operadores protestaban y las implementaciones alternativas mostraban casos límite. El mecanismo real de cumplimiento era la adopción: los estándares que funcionaban se difundían; los que no, se ignoraban o revisaban.
Por eso la gobernanza de Internet muchas veces pareció triaje de ingeniería: reducir ambigüedades, prevenir colisiones, mantener compatibilidad y entregar algo que la gente pudiera implementar. La meta no era política perfecta, sino una red que siguiera interconectándose.
La cultura de estándares de Internet—documentos ligeros, debate abierto y preferencia por código en funcionamiento—ayudó a que redes distintas interoperen rápido. Pero los mismos hábitos trajeron compromisos que se hicieron más difíciles de ignorar a medida que Internet creció de proyecto de investigación a infraestructura global.
“Abierto para cualquiera” no significó automáticamente “accesible para todos”. Participar requería tiempo, viajar (en los primeros años), fluidez en inglés y apoyo institucional. Eso creó representación desigual y, a veces, desequilibrios de poder sutiles: empresas o países con más recursos podían presentarse constantemente, mientras que otros luchaban por ser escuchados. Incluso cuando las decisiones eran públicas, la capacidad de dar forma a agendas y redactar textos concentraba influencia.
La preferencia por ser tolerante en lo que se acepta fomentó la compatibilidad, pero también pudo premiar especificaciones vagas. La ambigüedad deja espacio para implementaciones inconsistentes, y la inconsistencia se convierte en riesgo de seguridad cuando los sistemas hacen asumciones diferentes. “Ser indulgente” puede transformarse en aceptar entrada inesperada, lo que encanta a los atacantes.
Lanzar código interoperable pronto es valioso, pero puede sesgar resultados hacia equipos que implementan más rápido—ocasionalmente antes de que la comunidad explore privacidad, abuso o consecuencias operativas a largo plazo. Las correcciones posteriores son posibles, pero la compatibilidad hacia atrás hace que algunos errores sean caros de deshacer.
Muchas decisiones de diseño iniciales asumían una comunidad más pequeña y de confianza. A medida que llegaron incentivos comerciales, actores estatales y escala masiva, los debates de gobernanza resurgieron: quién decide, cómo se gana legitimidad y qué significa “consenso aproximado” cuando los riesgos abarcan resistencia a la censura, vigilancia e infraestructura crítica global.
Postel no “dirigió” Internet con un gran plan. Ayudó a que coherara tratando la compatibilidad como una práctica diaria: escribir las cosas, invitar a otros a probarlas y mantener los identificadores compartidos consistentes. Los equipos de producto modernos—especialmente los que construyen plataformas, APIs o integraciones—pueden adoptar esa mentalidad directamente.
Si dos equipos (o empresas) deben colaborar, no confíes en conocimiento tribal ni en “lo explicamos en una llamada”. Documenta tus interfaces: entradas, salidas, casos de error y restricciones.
Una regla simple: si afecta a otro sistema, merece una especificación escrita. Esa especificación puede ser ligera, pero debe ser pública para quienes dependen de ella.
Los problemas de interoperabilidad se esconden hasta que ejecutas tráfico real entre implementaciones reales. Publica un borrador, construye una implementación de referencia básica e invita a socios a probar mientras aún es fácil cambiar.
Especificaciones compartidas e implementaciones de referencia reducen la ambigüedad y dan a todos un punto de partida concreto en lugar de guerras de interpretación.
La compatibilidad no es una sensación; es algo que puedes probar.
Define criterios de éxito (qué significa “funcionar juntos”), luego crea pruebas de conformidad y objetivos de compatibilidad que los equipos puedan ejecutar en CI. Cuando los socios puedan ejecutar las mismas pruebas, los desacuerdos se vuelven errores accionables en lugar de debates interminables.
La estabilidad requiere un camino predecible para el cambio:
La lección práctica de Postel es simple: la coordinación escala cuando reduces sorpresas—tanto para humanos como para máquinas.
Una razón por la que la IETF podía converger es que las ideas no permanecían teóricas por mucho tiempo—se convertían en implementaciones ejecutables que otros podían probar. Los equipos modernos pueden beneficiarse del mismo bucle reduciendo la fricción entre “acordamos una interfaz” y “dos implementaciones independientes interoperen”.
Plataformas como Koder.ai son útiles en ese espíritu: puedes pasar de un boceto de API escrito a una aplicación web (React), backend (Go + PostgreSQL) o cliente móvil (Flutter) mediante un flujo de trabajo guiado por chat, luego iterar rápidamente con snapshots/rollback y exportación de código fuente. La herramienta no es el estándar—pero puede facilitar prácticas semejantes a las de los estándares (contratos claros, prototipado rápido, implementaciones reproducibles) para practicarlas de forma consistente.
La interoperabilidad no era automática porque las redes iniciales eran un mosaico de sistemas separados con supuestos distintos: formatos de direcciones, tamaños de mensajes, temporizadores de reintento, manejo de errores e incluso incentivos diferentes.
Sin acuerdos compartidos, se obtienen “islas” desconectadas que solo se unen mediante puertas de enlace frágiles y personalizadas.
Los puentes y conversores de protocolos personalizados son caros de construir y mantener, fáciles de romper cuando cambia cualquiera de las partes y tienden a convertirse en puntos de estrangulamiento.
Eso crea bloqueo por parte de proveedores u operadores, porque quien controla la “capa de traducción” puede imponer condiciones y frenar a la competencia.
Porque el “mejor” protocolo no gana si no puede implementarse de forma amplia y consistente.
Un estándar algo imperfecto pero fácilmente implementable puede conectar más redes que una solución técnicamente elegante que solo funciona dentro de un único ecosistema.
Influyó mediante la confianza ganada, no por autoridad formal: escritura clara, coordinación paciente y persistencia en el seguimiento.
También se ocupó de tareas poco glamurosas (editar, clarificar, empujar decisiones, mantener registros) que mantienen alineados a implementadores independientes.
Un RFC (Request for Comments) es un memo público que describe cómo debe funcionar un protocolo o una práctica de Internet.
En la práctica, da a los implementadores una referencia compartida: formatos, casos límite y comportamientos escritos para que distintos equipos puedan construir sistemas compatibles.
“Consenso aproximado” significa que el grupo busca un amplio acuerdo sin exigir unanimidad.
“Código en ejecución” implica que las propuestas deben demostrarse mediante implementaciones reales—idealmente varias independientes—para que la especificación refleje lo que realmente funciona en redes reales.
Fragmentación significaría mini-redes incompatibles con duplicación de la infraestructura básica y traducciones constantes.
Los costes se manifiestan como:
IETF ofrece un proceso abierto donde cualquiera puede leer borradores, unirse a discusiones y contribuir con evidencia desde la implementación y la operación.
En lugar de una jerarquía, la influencia se gana haciendo el trabajo: escribir borradores, probar ideas, responder a revisiones y mejorar la claridad hasta que los sistemas interoperen.
IANA mantiene registros compartidos (números de protocolo, puertos, códigos de parámetros y partes de la coordinación de nombres) para que implementaciones independientes usen los mismos valores.
Sin una referencia única, ocurren colisiones (mismo número, distinto significado) e incompatibilidades difíciles de depurar que socavan estándares correctos.
La guía de Postel—sé estricto con lo que envías, flexible con lo que aceptas—ayudó a que sistemas imperfectos se comunicaran.
Pero la tolerancia excesiva puede normalizar entradas malformadas y crear fallos de seguridad e inter-operabilidad. La versión moderna es compatibilidad con protecciones: validar estrictamente, documentar excepciones, registrar/limitar la no conformidad y retirarla progresivamente.