Resumen

  • RFC 1283 definió de forma experimental SNMP sobre servicios OSI sin conexión y orientados a conexión. COTS exigía abrir una conexión, enviar uno o varios mensajes y liberarla.
  • El iniciador no debía exigir que la respuesta regresara por esa conexión ni atribuirle la fiabilidad de la operación SNMP. Espera, retransmisión y abandono seguían en la aplicación.
  • RFC 1418 eliminó después el mapping COTS y conservó CLTS para entornos sin UDP. La sustitución documental no demuestra que toda implementación desapareciera al mismo tiempo.

La revisión recogía experiencia, no proclamaba un triunfo

RFC 1161 publicó en junio de 1990 una vía experimental para usar SNMP sobre transportes OSI. No era un estándar de Internet; sólo contemplaba una revisión futura después de experimentar y alcanzar consenso suficiente.

En diciembre de 1991, RFC 1283 lo dejó obsoleto y siguió siendo Experimental. Su editor explicó que la revisión reflejaba experiencia operativa. Eso prueba aprendizaje en el documento, no el resultado de una red concreta.

La motivación era reutilizar la inversión en SNMP cuando sitios con redes TCP/IP adquirían capacidades OSI. En vez de reconstruir SNMP como aplicación OSI, el RFC lo conectó directamente con los servicios de transporte.

CLTS mantenía el modelo de paquete

CLTS se parecía a UDP: ambos entregaban paquetes con información completa de direccionamiento. La dirección de transporte combinaba una dirección de red y un selector.

En este entorno no se usaban los puertos conocidos de Internet. Bytes opacos, de significado local en el destino, resolvían la demultiplexación. RFC 1283 coordinó snmp para tráfico ordinario y snmp-trap para avisos sobre CLNP.

El selector permitía entregar una unidad al servicio local correcto. No autenticaba al gestor, no autorizaba Set ni verificaba el contenido de una variable. Dirección de entrega y mandato operativo eran registros distintos.

COTS añadía una asociación, no una conclusión

SNMP no necesitaba por naturaleza una conexión existente. El mapping COTS ordenaba abrirla, enviar uno o varios mensajes SNMP y cerrarla.

Cada paso podía observarse por separado. Una conexión podía no abrir. Podía abrir sin recibir una solicitud SNMP completa. Podía aceptar bytes y cerrarse antes de que la aplicación contestara. Un estado establecido sólo probaba el contrato del transporte; no demostraba decodificación, acceso autorizado, lectura, escritura ni resultado.

La respuesta no estaba atada a la conexión de ida

RFC 1283 decía que el iniciador no debía exigir que la respuesta regresara en la conexión por la que salió la solicitud. Si el respondedor enviaba mensajes SNMP por ella, debían contestar solicitudes recibidas allí.

La asociación ofrecía una regla condicional de correlación. Su silencio no demostraba que no hubiera respuesta por otra vía, y la conexión no era un identificador durable de operación.

La duración tampoco tenía un único dueño. Idealmente cerraba el iniciador; el respondedor podía cerrar por límites de recursos. El tiempo abierto era específico de la implementación y dependía de un algoritmo dinámico. Un cierre podía indicar política, presión, inactividad o fallo, no necesariamente el desenlace de SNMP.

El acuse del transporte no llegaba hasta SNMP

La advertencia principal de RFC 1283 era explícita: el iniciador no debía asociar fiabilidad con el uso de la conexión. Retransmitir mensajes seguía siendo tarea de la aplicación SNMP.

RFC 1270 separó el acuse del transporte de la entrega al proceso de destino. SNMP aún necesitaba su propio temporizador y procedimiento de reintento para saber si el software SNMP había recibido el paquete.

El transporte podía proteger sus bytes y aun así no cerrar el contrato de la aplicación. La respuesta correlacionada era otra prueba. Incluso una respuesta sólo declaraba el dato del agente; no verificaba por sí sola el estado físico de la red.

Mantener conexiones tenía tres facturas

RFC 1270 comparó tres políticas: una conexión permanente por objeto, una nueva por operación o un conjunto limitado con reemplazo. La primera acumulaba cientos o miles de registros y posible tráfico de keepalive. La segunda repetía establecimiento, cierre y TIME-WAIT. La tercera exigía información de uso y un algoritmo, y degeneraba en aperturas por operación cuando había más agentes que plazas.

La decisión sobre qué asociación conservar se convertía así en una nueva superficie de control. El transporte con estado no eliminaba la contabilidad; creaba otro libro.

RFC 1418 conservó sólo la vía sin conexión

En marzo de 1993, RFC 1418 dejó obsoletos RFC 1161 y RFC 1283. Retuvo CLTS para entornos donde UDP no estuviera disponible y rechazó la lectura de que cada agente debiera admitir varios mappings.

CLTS podía realizarse sobre un servicio de red sin conexión u orientado a conexión, con selectores distintos. El contrato visto por SNMP seguía siendo sin conexión. Una propiedad de la red inferior no ascendía automáticamente de capa.

Fuentes y límites

Las fuentes oficiales son RFC 1161, RFC 1270, RFC 1283 y RFC 1418. Prueban reglas y cambios documentales, no una implementación actual, identidad, autorización, conexión observada, solicitud, respuesta, reintento, caída o resultado. Ninguno aborda cuestiones de seguridad.