Resumen
- RFC 1227 permitió que procesos de usuario registraran subárboles MIB ante un agente SNMP local; el agente dividía peticiones, consultaba a los pares y componía una respuesta de red.
- La prioridad y el «efecto de montaje del subárbol» decidían qué par era visible. El valor resultante probaba una selección local, no propiedad permanente, exhaustividad ni verdad.
- Un Set repartido primero recababa aceptación o rechazo y después enviaba commit o rollback sin acuse final. Aceptar la preparación no probaba que todos hubieran aplicado el desenlace.
La respuesta llegó completa; su procedencia estaba repartida
RFC 1227, de mayo de 1991, abordó un límite práctico del agente SNMP. El agente podía leer variables del núcleo y archivos estables, pero un proceso de enrutamiento conservaba estado que no pertenecía al agente. SMUX evitó convertirlo en una copia central de todo: el proceso dueño del dato podía asociarse localmente y registrar la rama que sabía atender.
Desde la red, la estación seguía usando el SNMP de RFC 1157. El agente recibía Get, GetNext o Set, separaba las variables según los registros vigentes, enviaba PDU internos y correlacionaba las respuestas. Una dirección administrativa producía así una vista común sobre varios procesos.
El registro del RFC Editor clasifica hoy el documento como Historic; el Datatracker conserva su trayectoria. Esa ficha no demuestra uso en un equipo concreto. Sí sitúa una arquitectura en la que el interlocutor externo y la fuente efectiva del valor eran entidades distintas.
La SMI de RFC 1155 aportaba nombres de objetos; RFC 1212 aportaba el formato conciso usado para describir las tablas SMUX. Un mismo árbol sintáctico no garantizaba una sola base de datos ni una sola autoridad material.
La prioridad resolvía la ruta, no la propiedad
Cada registro indicaba un subárbol y una prioridad entera. Cuanto menor el número, mayor la prioridad. Varios pares podían registrar el mismo ámbito en posiciones diferentes. El valor -1 pedía la mejor posición disponible, aunque la política local permitía al agente asignar una peor.
Solo el registro ganador recibía operaciones. Además, el agente debía imponer el «efecto de montaje»: si un par montaba una rama más amplia que contenía registros estrechos de otros pares, esos registros quedaban ocultos para el encaminamiento. No hacía falta borrar una entrada para dejar de consultarla.
Una lectura de un OID, por tanto, decía qué ruta había resuelto el agente bajo el mapa efectivo de aquel momento. No decía que el par elegido fuera el productor original, que los pares ocultos coincidieran, que la rama estuviera completa ni que el valor correspondiera al estado físico.
El agente debía proteger los subárboles SNMP y SMUX frente a registros alrededor de ellos, y podía vedar otros ámbitos por decisión de implementación. Ganar una entrada en el espacio de nombres era una concesión local y revisable, no un mandato operativo ni un título sobre el servicio.
El siguiente objeto era una propuesta sometida a control
GetNext obligaba al par a comportarse como si conociera todo el MIB. Podía devolver un objeto situado fuera de su rama. El agente tenía que comprobar el alcance y, si el resultado escapaba, continuar la búsqueda con el par del siguiente subárbol registrado.
El orden que veía la estación no era una lista extraída de una única fuente. Cada paso podía combinar una propuesta del par, una verificación del agente y una nueva consulta. La coherencia visible era trabajo del intermediario.
Los identificadores de petición también marcaban esta separación. Si una petición externa originaba varios PDU para un mismo par, aquellos compartían un ID interno que no tenía por qué coincidir con el original. Para reconstruir el camino hacían falta registros explícitos de correlación; la semejanza numérica no estaba garantizada por el protocolo.
El consenso previo no era un recibo posterior
Cuando un Set afectaba a varios pares, el agente averiguaba primero quién aceptaba o rechazaba la operación sin que nadie la ejecutara. Un rechazo provocaba rollback para todos; la aceptación unánime provocaba commit.
Pero el SOutPDU final no recibía respuesta. El noError de la primera fase solo significaba que el par aceptaba la propuesta. El envío posterior de commit demostraba una decisión del agente y un intento de entrega; no demostraba recepción, aplicación, persistencia ni efecto en cada proceso.
La prueba de finalización debía venir de otra capa: una lectura posterior, estado del proceso, registro del dispositivo u observación independiente. También el rollback necesitaba confirmación externa. La transacción coordinaba intención y decisión, no certificaba el mundo después del mensaje final.
El inventario conservaba filas que ya no estaban vigentes
El MIB de SMUX incluía tablas de pares y árboles. Invalidar una fila no obligaba a eliminarla: la limpieza era específica de la implementación. Una estación debía examinar el campo de estado para distinguir presencia histórica de uso actual.
SimpleOpen llevaba un OID de identidad, una descripción y una contraseña. Una contraseña de longitud cero significaba ausencia de autenticación, y el RFC declaraba que no discutía seguridad. El rótulo de identidad no autenticaba por sí solo a una persona, una organización, su permiso ni la calidad del dato.
La asociación sobre TCP usaba el puerto 199 y BER proporcionaba sus propios límites. El registro IANA de servicios y puertos conserva el contexto de una asignación, no demuestra que exista un listener, una implementación o una sesión activa.
El logro de RFC 1227 fue mantener una interfaz estable sin fingir que toda la información residía en el mismo proceso. Su lección probatoria exige conservar por separado la respuesta externa, el registro efectivo, el par elegido, la decisión transaccional y el estado observado después.
Fuentes
- RFC 1227 — SNMP MUX Protocol and MIB
- Registro de RFC 1227 en RFC Editor
- Registro de RFC 1227 en IETF Datatracker
- RFC 1157 — Simple Network Management Protocol
- RFC 1155 — Structure and Identification of Management Information
- RFC 1212 — Concise MIB Definitions
- IANA — Service Name and Transport Protocol Port Number Registry
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
