Resumen

  • En su testimonio oral, John Day presentó el modelo de referencia OSI como un marco que ayudaba a organizar el trabajo de normalización, no como una instrucción para construir una pila fija.
  • RINA propuso después una arquitectura recursiva de comunicación entre procesos, y ProtoRINA probó una implementación acotada. Las fuentes citadas no demuestran ni una adopción generalizada ni la ausencia absoluta de uso.

Un dibujo no decide el orden de despliegue

La imagen de siete capas se presta a leerla como una lista de tareas: implementar una, luego la siguiente, hasta completar la red. El recuerdo de John Day apunta a otra función. En una historia oral grabada por el Computer History Museum en 2010, describió el modelo de referencia OSI como un marco para el trabajo de normalización que vendría después, no como un documento de implementación. Es el relato retrospectivo de Day, no una cita del estándar ni un sustituto de las actas de las reuniones.

Aun así, ayuda a distinguir una función duradera: un modelo compartido puede nombrar funciones y facilitar la discusión entre comités sin fijar la arquitectura de cada producto ni el orden en que una operadora deba desplegarlo.

Day participó en ese esfuerzo. En una entrevista de Boston University recordó que fue relator del modelo de referencia OSI y presidió el comité de arquitectura OSI de ANSI. El testimonio del museo también recoge su versión sobre la delegación estadounidense y las primeras deliberaciones. Estas fuentes lo sitúan dentro del proceso; no lo convierten en autor único de OSI ni transforman un marco colectivo en una orden universal a los operadores.

La diferencia importa porque a veces se atribuye a los estándares una capacidad de mando que no está implícita en un diagrama. Un modelo puede crear vocabulario común, separar un problema amplio en funciones debatibles y ayudar a coordinar propuestas de organizaciones distintas. Pero no aporta presupuesto de ingeniería, una ruta de migración, compatibilidad con equipos instalados ni una razón comercial para cambiar. Esas decisiones corresponden a quienes implementan y operan. Confundir descripción con instrucción exagera el poder de la normalización y hace que la adopción parezca automática.

RINA como propuesta recursiva

El trabajo posterior de Day no consistió en añadir una octava caja a OSI. En el artículo de 2008 «Networking is IPC», escrito junto con Ibrahim Matta y Karim Mattar, los autores propusieron entender las redes como comunicación entre procesos (IPC). Una aplicación utiliza una facilidad IPC; esa facilidad puede solicitar a su vez servicios de otra facilidad inferior. La repetición constituye la idea arquitectónica. Es una propuesta, no un inventario de redes que ya la hubieran adoptado.

El proyecto RINA de Boston University describe una facilidad distribuida de IPC (DIF) como unidad repetida y explica que distintas políticas pueden configurarla. Esa página expone el modelo de sus propios investigadores. Sirve para entender su intención, pero no es una evaluación independiente de rendimiento ni prueba que RINA haya desplazado al Internet público.

ProtoRINA hace visible la brecha entre arquitectura e implementación. En un artículo de 2014, Wang, Matta, Esposito y Day describieron un prototipo en espacio de usuario y pruebas en el campus de Boston University y en la plataforma de investigación GENI. El texto se identifica como nota editorial no revisada por pares. También dice que la implementación estaba incompleta y que usaba un adaptador TCP para las conexiones de nivel cero. Esos límites no invalidan el experimento: definen qué demuestra. Hubo software que puso a prueba una parte del diseño en entornos concretos.

No demuestra un despliegue comercial general, el reemplazo de Internet ni una superioridad comparativa.

Conviene separar tres preguntas: ¿qué define el modelo?, ¿qué ejecutó una implementación determinada? y ¿qué redes independientes la adoptaron, durante cuánto tiempo y a qué escala? El testimonio de Day ayuda a responder la primera; el artículo de RINA presenta una arquitectura; ProtoRINA documenta un experimento limitado. Las fuentes revisadas aquí no ofrecen un censo exhaustivo para la tercera. No sería riguroso concluir ni que «RINA está en todas partes» ni que «RINA no se usa en ningún sitio».

Coordinar no es ordenar

La aportación analítica de la trayectoria de Day no es proclamar un mapa definitivo de capas. Es mostrar el límite entre una especificación común y las decisiones locales. La normalización puede hacer comprensibles ciertas interfaces entre organizaciones. Aun así, cada operador decide si el modelo encaja con sus equipos, servicios, personal, riesgos y calendario de actualización. Un prototipo reduce incertidumbre sobre si el código funciona en un banco de pruebas; solo la evidencia de adopción permite saber quién aceptó el coste operativo y qué se mantuvo en producción.

Quien evalúe infraestructura debería pedir el respaldo concreto de cada afirmación. Un modelo debe explicar su alcance y uso previsto. Un prototipo debe indicar su estado, entorno, pruebas y partes pendientes. Una afirmación de despliegue requiere redes identificadas, fechas, funciones y una diferencia clara entre una prueba y un servicio sostenido. Sin esos registros, un dibujo puede adquirir una autoridad que ningún comité, artículo o experimento le concedió.

Fuentes