Resumen

  • RFC 1095 registra a CMOT y SNMP con idéntica condición de Draft Standard y Recommended. La política previa había reservado la urgencia operativa para SNMP y el horizonte largo para CMIS/CMIP, pero pedía implementación y experiencia con ambos.
  • Los dos grupos acordaron un MIB común de Internet. Compartir objetos no resolvía cómo conversar: CMOT necesitaba un perfil que enlazara CMIS, CMIP, ACSE, ROSE, ASN.1 y la presentación ligera con TCP o UDP.
  • El alcance terminaba en un único dominio de gestión; las aplicaciones quedaban fuera y los parámetros de control de acceso eran opcionales. Abrir una asociación o recibir una respuesta no equivalía a acreditar mandato ni resultado físico.

En 1989, «recomendado» todavía estaba en plural

La historia retrospectiva suele empezar por el desenlace: SNMP quedó incorporado al trabajo cotidiano y CMOT pasó a ser una alternativa recordada por su complejidad. RFC 1095 muestra una fotografía anterior. El IAB había otorgado a dos protocolos diferentes el mismo nivel de Draft Standard y el mismo rótulo Recommended.

La recomendación tenía una consecuencia concreta. Todo sistema IP/TCP que ofreciera gestión de red debía adoptar al menos uno. También era una invitación a experimentar: el IAB quería informes de constructores y usuarios de las dos familias.

No era, sin embargo, una proclamación de igualdad material. RFC 1052 había elegido un reparto temporal muy deliberado. SNMP debía cubrir el corto plazo porque había software disponible y funcionando. CMIS/CMIP debía desarrollarse y probarse como solución de largo plazo, capaz de conectar la experiencia de Internet con las normas ISO.

El programa daba respuesta a dos riesgos. Esperar a una arquitectura completa dejaba una red en rápido crecimiento sin herramientas; resolver sólo la urgencia podía encerrar el futuro en una solución provisional. Dar trabajo y rango a las dos rutas permitía aprender antes de clausurar la decisión.

La evidencia posterior debe leerse con la misma precisión. RFC 1109 enumeró implantaciones de SNMP ya presentes y no recibió noticia de una implementación CMOT públicamente disponible en su reunión de junio de 1989, aunque recogió planes de proveedores y de una demostración. Los prototipos de Interop ’88 citados por RFC 1095 demostraban que la arquitectura podía funcionar entre fabricantes; no medían su adopción.

El MIB común resolvía el nombre, no la operación

El acuerdo más duradero no fue escoger un paquete, sino un catálogo de objetos. RFC 1052 encargó un MIB común para que SNMP y el grupo Netman no construyeran dos representaciones incompatibles de la misma Internet. RFC 1109 habló después de unas cien variables obligatorias convenidas por ambos grupos.

Esa decisión permitía que un contador, una interfaz o una entrada de rutas conservaran significado aunque cambiara el protocolo que los consultaba. Incluso se esperaba que la continuidad facilitara el tránsito desde la solución de corto plazo hacia CMIP.

Pero nombrar la misma cosa no obliga a preguntar de la misma forma. Falta decidir cómo identificar una instancia, limitar el alcance, aplicar filtros, ordenar respuestas, anunciar eventos, negociar una sesión y codificar errores. También falta construir la herramienta con la que una persona vea, correlacione y actúe.

RFC 1109 puso el foco justamente allí: la eficacia de la gestión dependería de las aplicaciones disponibles para operadores, no sólo del protocolo subyacente. Ni SNMP ni CMIS ofrecían entonces una noción temporal capaz de pedir datos históricos o programar una orden futura.

El MIB era una capa semántica valiosa, pero incompleta. RFC 1095 necesitó perfilar el resto para que dos implementaciones no se limitaran a reconocer los mismos sustantivos mientras hablaban lenguajes incompatibles.

Un perfil es una lista de decisiones, no una etiqueta

Para implementar CMOT no bastaba con colocar CMIP encima de TCP. ASN.1 representaba los datos; ACSE abría y cerraba asociaciones; ROSE llevaba operaciones remotas; CMIS y CMIP definían los servicios y mensajes; SMI y MIB describían los objetos; RFC 1085 aportaba la presentación ligera.

Por eso RFC 1095 concreta unidades funcionales, contexto de aplicación, clases e instancias, alcance, filtros, sincronización y PDU. Luego establece cómo ACSE, ROSE y CMIP atraviesan la capa de presentación. La interoperabilidad se escondía en esas elecciones pequeñas.

La capa ligera evitaba implementar toda la pila OSI de presentación, sesión y transporte. Conservaba los servicios que esperaban los elementos de aplicación y los vinculaba a transportes de Internet. Era una reducción de costo, no la desaparición de la arquitectura.

Decir «CMIP compatible» no revela qué contexto, qué opciones, qué versión del MIB, qué codificación ni qué transporte existen. El perfil convierte una familia amplia de normas en un punto de encuentro verificable. También deja claro lo que no certifica: la calidad de la aplicación, la fidelidad del agente o el derecho del emisor.

La abstracción no igualó TCP y UDP

RFC 1085 llamó de alta calidad al mapeo sobre TCP y de baja calidad al mapeo sobre UDP. Su advertencia era tajante: baja calidad significa baja calidad. La presentación no añadía por arte de magia conexión, orden o recuperación a UDP.

RFC 1095 permitió los dos caminos. Reservó los puertos 163 para gestores y 164 para agentes tanto en TCP como en UDP. Para UDP fijó 484 octetos como tamaño máximo del PDU bajo el objetivo de evitar fragmentación. La localización del agente podía proceder de un directorio, una tabla local o un intento de asociación.

Así, una dirección sin contexto no describía el endpoint. Había que conservar transporte, función, perfil y origen del descubrimiento. Un socket TCP abierto y un datagrama UDP recibido aportaban pruebas distintas sobre la entrega. Ninguno decía quién tenía autoridad organizativa para ordenar el cambio.

También explicaban fallos distintos. El silencio podía ser pérdida de red, incompatibilidad de presentación, rechazo de asociación, función CMIS ausente, denegación de acceso o problema del objeto. Una sola alarma «CMOT caído» borraba la explicación.

El círculo del estándar contenía un dominio

CMOT utilizaba managers y agents y se presentaba como base para las cinco áreas funcionales de gestión OSI. Pero RFC 1095 no normalizaba las aplicaciones que debían realizar esas tareas. Sólo buscaba la arquitectura mínima para interoperación entre proveedores; el producto que usaba el operador seguía abierto a competencia.

Otra exclusión era aún más importante: las relaciones entre dominios de gestión. La arquitectura cubría un solo dominio. Eso no equivale simplemente a una red IP.

Un dominio reúne delegación, política y responsabilidad. Decide qué sistemas pueden mandar, qué equipos responden y quién asume el resultado. El enrutamiento puede llevar un paquete de una organización a otra, pero no transporta por sí mismo esa delegación.

El protocolo podía describir un pedido dirigido a un agente. No podía autorizar al administrador de otra institución ni repartir las consecuencias de modificar un recurso ajeno. La federación necesitaba acuerdos superiores al perfil.

La simetría de mensajes tampoco resolvía esa cuestión. Dos extremos pueden implementar roles compatibles; sus poderes no tienen por qué ser equivalentes. La autoridad sigue siendo delimitada y revocable.

Aceptar la asociación sólo abría la conversación

ACSE negociaba el contexto de aplicación y las unidades funcionales antes de intercambiar operaciones. Si la asociación era aceptada, existía evidencia de compatibilidad entre dos pilas.

No era evidencia suficiente de identidad o mandato. RFC 1095 trató como opcionales los parámetros de control de acceso tanto en la asociación como en cada petición. Recomendó resolver el acceso en la asociación y esperó futuros mecanismos de autenticación para TCP/IP, pero permitía ignorar el campo de la petición. Una técnica provisional podía ser una contraseña sin cifrar.

Esas opciones muestran que el problema estaba identificado, no que hubiera desaparecido. RFC 1109 volvió a señalar el control de usuarios y la autenticación de órdenes y respuestas como terrenos no cubiertos por ninguna de las dos especificaciones.

La secuencia correcta conserva cuatro decisiones. Alcance de red: se puede intentar. Compatibilidad de perfil: se puede conversar. Autenticación: se atribuye el mensaje a un principal bajo un método. Autorización: una política permite esa operación. Saltar una decisión convierte interoperación en poder supuesto.

La respuesta del agente no era todavía el resultado

CMIS ofrecía lecturas, cambios y notificaciones con una estructura expresiva. Sin embargo, RFC 1095 sólo exigía sincronización de mejor esfuerzo; la sincronización atómica era opcional. No prometía una transacción universal sobre el hardware.

Una respuesta positiva acredita que la pila recibió y procesó la solicitud y que el agente comunicó el estado previsto por la operación. No acredita por sí sola que una tarjeta conmutó, que el tráfico cambió de ruta, que la configuración persistió o que el servicio mejoró.

Para eso hacen falta observaciones posteriores: otra lectura, un evento, un contador independiente, una comprobación de persistencia o una medición externa. Si confirmación y orden proceden del mismo agente, conviene anotar esa dependencia.

No es una objeción a CMOT. Es una asignación correcta de capas. El protocolo define significado y transporte. La instrumentación lo lleva al dispositivo. El dispositivo y la red producen consecuencias. Cada límite requiere su propia prueba.

La revisión demostró que el perfil también tiene versión

RFC 1189 sustituyó a RFC 1095 en octubre de 1990, cuando CMIS/CMIP ya se apoyaban en normas ISO finales. Eliminó el tutorial, separó la semántica del MIB, incorporó acuerdos actualizados y cambió la negociación de asociación, manteniendo reconocimiento del antiguo contexto.

Una etiqueta de protocolo no podía expresar ese historial. Cuando cambiaba la norma base, el perfil debía fijar qué versión, opciones y contexto seguían encontrándose.

La escena de 1989 deja una lección más amplia que la competencia entre siglas. Un catálogo común, una entrega compatible, un permiso institucional y un efecto comprobado son logros diferentes. RFC 1095 sólo unía algunos; su honestidad consiste en señalar el borde.

Fuentes