Resumen

  • RowStatus distingue acciones que solo se escriben (createAndGo, createAndWait, destroy) de estados que se pueden observar (active, notInService, notReady). La petición de un gestor no se confunde con la situación que el agente puede confirmar.
  • Una fila incompleta puede existir, consumir recursos y ser retomada, pero no queda reservada de forma exclusiva ni tiene garantizada la activación. La atomicidad y el retroceso de un SetRequest se limitan a esa petición, no al ciclo completo ni a varios dispositivos.

La operación terminó, el recurso no

Una creación por etapas tiene una ventaja evidente: permite proporcionar los datos cuando están disponibles. También crea un problema de custodia. Si el gestor desaparece después del primer paso, el dispositivo conserva algo que todavía no usa. Otro gestor necesita saber si se trata de una fila válida, de un trabajo incompleto o de un recurso que debe recuperarse.

RFC 2579 convirtió esa diferencia en la convención textual RowStatus. Sus seis valores no forman una lista homogénea. active y notInService son estados que se leen y se escriben. notReady es un estado que se lee, pero no se escribe. createAndGo, createAndWait y destroy son acciones que se escriben y nunca se leen.

Por eso el gestor que escribe createAndWait no espera encontrar esa misma palabra como estado persistente. El agente crea la fila y muestra una consecuencia. Si falta información necesaria, el estado es notReady; si hay datos suficientes para intentar ponerla en servicio, es notInService.

La fila notReady no equivale a una creación rechazada. Puede tener índice, columnas y recursos ya asignados. La fila notInService tampoco prueba que la configuración sea correcta o que haya capacidad para activarla. Solo dice que el agente ha llegado al punto en que puede considerar el intento.

Limpiar no es adivinar la intención

Si el gestor no vuelve, la fila puede quedarse indefinidamente fuera de servicio y consumiendo recursos. RFC 2579 no deja ese caso a la esperanza. El agente debe detectar las filas que han permanecido un tiempo anormalmente largo en notReady o notInService y retirarlas.

El plazo no es universal. La DESCRIPTION de la columna de estado debe indicar qué duración se considera anormal. Solo cuando no lo hace, el RFC sugiere aproximadamente cinco minutos. Presentar esa cifra como un temporizador obligatorio para todos los equipos borraría la decisión que corresponde al diseñador de cada objeto.

La regla también alcanza a filas que antes estuvieron activas y luego quedaron demasiado tiempo en notInService. No es solamente un recolector de intentos nuevos fallidos. Reconoce que cualquier estado intermedio prolongado puede inmovilizar capacidad.

Esta responsabilidad del agente no convierte la eliminación en un juicio sobre la intención del operador. Es un límite de recursos cuando el participante remoto ha dejado de avanzar. El plazo debe equilibrar la oportunidad de recuperación con el coste que se impone a otros usuarios de la tabla.

El PDU fija una frontera y no una historia completa

La escritura de varias columnas sí dispone de una garantía acotada. RFC 3416 define que el agente valida primero las vinculaciones de variables de un SetRequest. Las asignaciones de esa misma petición ocurren como si fueran simultáneas entre sí. Si una falla después de la validación, se deshacen las demás y se devuelve commitFailed; si no es posible deshacerlas todas, se devuelve undoFailed.

Esto permite agrupar columnas y una acción de creación en una petición con un límite de commit comprensible. No convierte la secuencia de crear y esperar, leer, completar columnas y activar en una sola unidad. Cada respuesta cierra una petición. Entre una y la siguiente puede haber una caída, una carrera o una modificación del propio dispositivo.

El retroceso de la última petición no borra las peticiones anteriores. Tampoco coordina varios agentes. La frase «como si fueran simultáneas» se refiere a las asignaciones dentro de un PDU, no a una transacción distribuida sobre una red de dispositivos.

La existencia de undoFailed es una advertencia adicional: incluso dentro de la frontera local, el gestor debe releer el estado real cuando el agente no consigue restaurarlo por completo. Un nombre de error no es prueba de que todo haya quedado intacto.

La fila incompleta puede enseñar qué le falta

createAndWait permite crear una fila cuando el gestor aún no conoce cada dato obligatorio. Después de leer notReady, puede consultar las columnas. Las instancias obligatorias que todavía no existen devuelven noSuchInstance; el gestor puede inicializarlas. Cuando la información alcanza el umbral necesario, el estado cambia a notInService.

Así, el progreso queda en la interfaz administrada y no solo en la memoria del cliente. Un operador puede retomar el trabajo después de un reinicio. Otro gestor puede diferenciar una fila ausente de una fila que existe pero aún no sirve. La incompletitud deja una evidencia local y verificable.

Sin embargo, el cambio a notInService no sustituye la decisión de activación. Al escribir active, el gestor todavía puede recibir inconsistentValue. El agente puede descubrir que los valores no forman una combinación aceptable o que no dispone de recursos. Tener todas las piezas no demuestra que el resultado deba ponerse en funcionamiento.

Las definiciones de cada tabla conservan su propia política de modificación. Su DESCRIPTION puede exigir sacar una fila de servicio antes de cambiar determinadas columnas, o permitir algunos cambios mientras está activa. No es correcto convertir el comportamiento de una tabla en una regla para todas las que usan RowStatus.

El intervalo deja espacio a otro actor

La espera visible no es un bloqueo. RFC 2579 advierte que el dispositivo administrado puede crear su propia instancia entre la petición createAndWait y la posterior petición active. Si eso ocurre, los valores que mantiene el agente pueden prevalecer sobre los que había enviado el gestor.

La primera respuesta, por tanto, no entrega propiedad exclusiva sobre el índice. Antes de activar, releer las columnas importantes es una comprobación de concurrencia. Un cambio inesperado no debería borrarse automáticamente con un reintento, porque puede ser la evidencia de que otro actor tomó una decisión durante la pausa.

destroy también es una acción y no un estado de reposo. Puede solicitarse cuando la fila está active, notInService o notReady. Si tiene éxito, se eliminan todas las instancias de la fila. La ausencia posterior es el resultado; no existe una fila que permanezca con estado destroy para documentar su propia desaparición.

La solución nació en una tabla compartida

El SNMP de RFC 1157, publicado en mayo de 1990, representaba las funciones de un agente como lecturas y alteraciones de variables con nombre. Era una forma deliberadamente pequeña de administrar equipos diferentes sin estandarizar una orden especial para cada función.

Una fila conceptual introducía tiempo y relación entre valores. Podía necesitar un índice libre, varias columnas obligatorias, coherencia entre ellas y una reserva de recursos. Varios gestores podían intentar usar la misma tabla. El propio dispositivo podía producir una instancia. La capacidad de cambiar variables no explicaba por sí sola cómo exponer una creación parcial ni quién la retiraría después de un abandono.

RMON hizo concreto el problema. RFC 1271, de noviembre de 1991, describió tablas de control para compartir recursos de monitorización entre varios gestores. Su EntryStatus empleaba createRequest, underCreation, valid e invalid. El texto contemplaba colisiones, gestores que fallaban y cadenas de propietario para que los participantes pudieran reconocer quién había configurado una entrada.

Una cadena de propietario no autentica al gestor ni le concede autoridad. Lo que aportaba era visibilidad operativa. La creación dejó de ser una transición invisible entre nada y una fila válida; podía tener una fase intermedia que otros debían interpretar.

RFC 1443 generalizó el patrón en abril de 1993 y señaló expresamente su origen en EntryStatus. RFC 1903 revisó la convención en 1996. RFC 2579, de 1999, contiene el ciclo detallado que sirve de base a este análisis. La interfaz general se formó a partir de un problema específico de operación, no de una analogía abstracta con una base de datos.

Un resultado distinto para cada etapa

RowStatus no elimina el fracaso. Permite decir quién debe actuar y qué puede comprobarse. El gestor solicita la creación, aporta valores y decide cuándo pedir la activación. El agente decide si puede crear la instancia, si hay información suficiente, si los valores son coherentes, si existen recursos y cuándo limpiar una fila abandonada. La definición de la tabla fija restricciones y plazos particulares.

Esa división produce afirmaciones más pequeñas que un único mensaje de éxito. La petición fue aceptada. La fila existe. La información está completa. El agente aceptó activarla. El servicio produjo el efecto esperado. Ninguna de estas frases reemplaza automáticamente a la siguiente.

La fila que existía antes de estar lista era precisamente la parte que un sistema binario habría ocultado. Al darle un estado legible y una vida limitada, SNMP pudo conservar operaciones sencillas sin fingir que una configuración compuesta era un solo valor instantáneo.

Fuentes