Resumen

  • En RowStatus, active, notInService y notReady son estados observables; createAndGo, createAndWait y destroy son peticiones que nunca aparecen como resultado de una lectura.
  • El gestor propone el índice y los valores, pero el agente aplica las reglas de la MIB. Por eso una fila puede existir sin estar completa y estar completa sin estar disponible para el dispositivo.

Las primeras filas eran una convención

Una MIB podía dibujarse como una tabla y recorrerse por columnas e índices. Sin embargo, RFC 1212 advertía que esas tablas y filas eran conceptuales: la relación entre sus objetos la imponían las aplicaciones, no una maquinaria relacional dentro de SNMP.

Para eliminar una fila, cada MIB podía reservar un entero como invalid. Para crearla, un SetRequest podía nombrar instancias todavía inexistentes, que el agente aceptaba o rechazaba. DEFVAL ayudaba a rellenar columnas omitidas. El protocolo ofrecía piezas, pero no un ciclo de vida uniforme.

El hueco se volvió evidente cuando varios gestores escribían configuración. Una estación podía escoger un índice y crear algunas columnas mientras otra observaba o intentaba usar la misma fila. Existencia física en el agente, información suficiente y efecto operativo necesitaban límites separados.

RMON introdujo la fila en construcción

La MIB de monitorización remota de RFC 1271 ensayó una solución. EntryStatus distinguía createRequest, underCreation, valid e invalid. El primer gestor que conseguía crear el índice se quedaba con la fila; los competidores recibían un error. Después podía completar los valores y marcar la entrada como válida.

Un OwnerString identificaba a quien había creado el recurso. Servía para que gestores cooperativos evitaran pisarse, pero el propio RFC negaba que fuera control de acceso. Un gestor que no cooperara aún podía modificar o borrar la entrada. Saber quién declaró algo no equivale a concederle exclusividad.

Ese precursor mostró las dos preguntas que RowStatus debía contestar sin mezclarlas: ¿qué quiere hacer el gestor y qué condición puede afirmar ahora el agente?

Seis números, pero solo tres estados

RFC 1443 incorporó RowStatus a SNMPv2. Su definición vigente en RFC 2579 asigna seis valores con dos naturalezas distintas.

Una lectura devuelve active(1) cuando la fila está disponible para el dispositivo; notInService(2) cuando existe y permanece fuera de servicio aunque el agente tiene información suficiente para intentar activarla; o notReady(3) cuando faltan instancias de columnas necesarias. notInService no certifica coherencia, recursos disponibles ni éxito futuro.

Una escritura puede pedir createAndGo(4), que combina creación y activación; createAndWait(5), que crea sin servir; o destroy(6), que solicita eliminar todas las instancias de la fila. Esos tres valores son verbos de entrada. Un GET nunca los devuelve.

El gestor tampoco puede establecer notReady. Solo el agente puede informar de esa condición. La asimetría evita que la orden de “crear y seguir” se archive como si fuera prueba de que la fila llegó a estar activa.

Crear de una vez era una decisión binaria

Con createAndGo, el gestor envía en una sola petición el nuevo RowStatus y las columnas que considera necesarias. El agente puede completar algunas mediante valores predeterminados. Luego decide si dispone de información suficiente para que el dispositivo use la fila.

Si la respuesta es afirmativa, crea la fila y el estado observable pasa directamente a active. Si falta información, responde inconsistentValue y no crea la fila. El fallo no deja un borrador normalizado. El gestor debe añadir lo que falta y repetir, o recurrir a la creación gradual cuando esté disponible.

La regla hace que una operación compacta sea comprensible: activación inmediata significa éxito completo, no restos parciales que otro observador deba interpretar.

Esperar convertía la preparación en un estado visible

createAndWait acepta que la creación tenga varias interacciones. Tras una respuesta correcta, la fila ya existe pero el dispositivo no la usa. Si faltan columnas obligatorias, una lectura muestra notReady. Cuando se proporcionan, el agente puede cambiarla a notInService, señal de que hay material suficiente para intentar la activación, no promesa de que vaya a aceptarla.

El gestor escribe después active. La transición puede triunfar o fallar con inconsistentValue por valores incompatibles, recursos o estado del dispositivo. Un agente también puede rechazar createAndWait con wrongValue; en ese caso exige la creación completa en una sola petición.

La pausa no puede consumir recursos sin límite. RFC 2579 obliga al agente a detectar filas que permanecen demasiado tiempo en notReady o notInService y eliminarlas. La descripción de la MIB debería fijar el plazo; si no lo hace, el RFC sugiere unos cinco minutos para incluir el tiempo de reacción humana. No es un valor demostrado para todos los productos.

Las reglas concretas seguían viviendo en la MIB

RowStatus no determina si una columna puede cambiar mientras la fila está activa. Algunas MIB lo permiten; otras exigen retirarla de servicio. El agente puede negarse a suspender o destruir una fila que está en uso.

La cláusula DESCRIPTION debe enumerar la información necesaria para activar y las restricciones de modificación. RFC 4181 convirtió esa claridad en práctica recomendada: una tabla con creación dinámica debería tener una columna RowStatus read-create, documentar su persistencia o StorageType, explicar cuándo el propio agente crea o elimina filas y declarar las condiciones de activación.

La convención compartida no sustituyó a la política local. La hizo legible: una misma gramática de estados rodeada por requisitos específicos de cada objeto administrado.

Una petición era atómica solo dentro de su frontera

Las columnas y RowStatus suelen viajar juntas. RFC 3416 trata conceptualmente un SetRequest en dos fases: primero valida cada variable; solo si todas pasan, altera sus valores. Las asignaciones ocurren como si fueran simultáneas respecto de las demás asignaciones de esa petición.

Si una modificación falla, la entidad intenta deshacer las otras y devuelve commitFailed. Si no puede deshacerlo todo, devuelve undoFailed. La segunda respuesta impide vender una abstracción perfecta donde el propio estándar reconoce un borde de recuperación.

La semántica alcanza una petición en una entidad SNMP. No es una transacción entre varios equipos, no garantiza almacenamiento duradero y no prueba que el plano de datos produzca el resultado deseado. Una respuesta correcta autoriza una conclusión de gestión limitada; el servicio requiere otra observación.

El avance fue no fingir que presencia significaba funcionamiento

RowStatus reparte el conocimiento. El gestor expresa el cambio. La MIB declara el contrato. El agente comprueba acceso, valores, recursos y transición. El equipo en ejecución decide la realidad final.

Una fila visible puede estar incompleta. Una fila completa puede estar deliberadamente fuera de servicio. Una solicitud de activación puede fallar. Incluso active no dice que la configuración sobreviva al reinicio ni que el tráfico funcione. El estado sirve porque conserva esas fronteras.

Fuentes y límites

RFC 1212 y RFC 1271 documentan el punto de partida y el precursor RMON. RFC 1443 y RFC 2579 definen RowStatus. RFC 3416 delimita SetRequest, y RFC 4181 recoge la disciplina posterior para diseñar MIB. Estas fuentes no miden despliegue moderno, conformidad de fabricantes, seguridad, temporizadores reales ni efecto en el tráfico. La lectura de RowStatus como separación entre intención, preparación y servicio es una inferencia del diseño.