Summary

  • RowStatus divides readable states—active, notInService and notReady—from write-only actions—createAndGo, createAndWait and destroy. The manager's request is not presented as the condition the agent can confirm afterward.
  • createAndWait makes an incomplete row visible and recoverable without granting an exclusive reservation or promising activation. Simultaneous assignment and rollback apply within one SetRequest, not across the later exchanges or across devices.

An action that could not become its own evidence

Suppose a management application wants to create a new filter, measurement or policy row. It knows the index and some columns but not every required value. If it writes createAndWait, the agent can create the conceptual row without putting it into service.

The next read does not echo the request. RFC 2579 defines six RowStatus values in two different roles. active and notInService are states that may be read or written. notReady is a state that may be read but not written. createAndGo, createAndWait and destroy are actions that may be written but are never read.

If creation succeeds with insufficient information, the agent reports notReady. If enough information exists to attempt to make the row available to the managed device, it reports notInService. The written action has finished; the readable state describes the narrower fact left behind.

This distinction prevents two false conclusions. A notReady row is not necessarily a failed creation. It may already have an index, column instances and allocated resources. A notInService row is not certified correct. It has crossed an information threshold, not the final decision to activate it.

Had the agent simply returned createAndWait, the interface would have confused an instruction with its consequence. By refusing to make the action readable, RowStatus made the manager ask what the device could actually establish.

A small variable model met a row-shaped process

The SNMP described in May 1990 by RFC 1157 deliberately represented agent functions as reads and alterations of named variables. The design avoided an expanding catalogue of imperative commands peculiar to each kind of equipment.

A conceptual row complicated that model without requiring it to be abandoned. Creating one could require a collision-free index, several columns with no defaults, consistency among values and allocation of scarce resources. More than one management station might use the same control table. The managed device might create an instance of its own.

The ability to set variables did not by itself say how partial work should be exposed, how another manager could resume it or who should recover its resources if the initiator vanished. A row needed a life between absence and service.

Remote monitoring supplied an early operational case. RFC 1271, published in November 1991, described RMON control tables in which multiple managers shared monitoring resources. Its EntryStatus used createRequest, underCreation, valid and invalid. The surrounding procedure considered collisions, failed managers, abandoned entries and an owner string that helped participants understand who had configured an entry.

An owner string was neither authentication nor authorization. It added context, not authority. The more durable move was to acknowledge that creation occupied time, could be observed by others and could be left unfinished.

In April 1993, RFC 1443 generalized the pattern as the RowStatus textual convention and explicitly identified RMON's EntryStatus as its origin. RFC 1903 revised the convention in 1996. RFC 2579's 1999 text provides the detailed lifecycle used here. A problem first made concrete in one family of control tables became a reusable interface for many MIB modules.

Creating a row in order to learn what it lacked

createAndWait supports a manager that cannot supply every mandatory value at the first step. Once the row reads notReady, the manager can inspect its columns. A required instance that does not yet exist produces noSuchInstance. The manager can initialize those instances, and the row becomes notInService when the required information is present.

Partial progress therefore lives at the managed interface rather than only in the initiating client's memory. If that client restarts, an operator can read the row. A second manager can distinguish absence from incomplete existence. The intermediate condition becomes shareable evidence.

The move to notInService still does not validate the configuration. When the manager later writes active, the agent can reject the transition with inconsistentValue. Columns can all be present while their combination remains unacceptable. Resources can be unavailable, or local conditions can have changed.

Ready to attempt activation is a deliberately smaller statement than ready for service. The agent retains a decision boundary between completeness and acceptance.

Individual object definitions retain policy as well. Their DESCRIPTION clauses can specify whether columns may change while a row is active, whether it must first move out of service, or whether the agent may refuse suspension. One table's edit behavior must not be projected onto every use of RowStatus.

Waiting did not reserve the row

An incomplete row can look like a reservation owned by the manager that created it. RFC 2579 warns against that reading. Between the set operation that writes createAndWait and the later one that writes active, the managed device can create its own instance. Values held by the agent may then supersede the values supplied by the manager.

The multi-exchange lifecycle opens a competition window. Visibility is not a lock. The first writer does not obtain exclusive title to the index merely by receiving a successful creation response.

Reading decisive columns again before activation is therefore a concurrency check, not redundant ceremony. An unexpected change can be evidence that another actor moved during the wait. A retry loop that blindly restores its original values may erase the only visible sign of that conflict.

destroy follows the same action-and-state separation. It can be requested whether the row is active, notInService or notReady. If the operation succeeds, all instances belonging to the conceptual row are removed. There is no surviving row whose readable status is destroy; absence is the action's result.

If an operator needs a historical deletion record, it must preserve the request, prior readback and authorization in an audit system. RowStatus describes the current lifecycle. It is not an event ledger.

The agent could not wait forever

Staged creation makes recovery possible, but it also permits abandonment. A manager process can crash after creation. The network can fail. An operator can leave the task. The row remains unavailable to the device while still consuming memory, a table slot or a monitoring resource.

RFC 2579 assigns cleanup to the agent. It must detect conceptual rows that have remained in notReady or notInService for an abnormally long time and remove them. The status column's DESCRIPTION is responsible for defining that period. Only when it does not does the RFC suggest approximately five minutes.

Five minutes is consequently not a universal timeout. A scarce resource may justify quicker recovery. A legitimate workflow awaiting an external approval may need longer. The duration distributes capacity and recovery opportunity among competing users of the table.

The cleanup rule also applies to a previously active row left out of service for too long. It is not limited to new creation attempts. Any intermediate state that holds resources beyond its expected duration creates a recovery obligation.

The agent holds the local resource and therefore owns the last-resort cleanup mechanism. It does not, however, know the absent manager's intention. The object definition must make the tradeoff explicit rather than hiding it behind an assumed implementation default.

One request had a stronger boundary than the lifecycle

SNMP's write procedure is stronger than a sequence of arbitrary column changes. RFC 3416 requires the agent to validate the variable bindings in a SetRequest before assignment. Assignments in the same request occur as if simultaneously with respect to one another. If an assignment then fails, the others are undone and the response reports commitFailed. If all assignments cannot be undone, it reports undoFailed.

This is a useful and exact boundary. A manager can place several columns and a creation action in one PDU and obtain common treatment for that request.

It does not wrap a sequence of createAndWait, later reads, additional column writes and activation into one transaction. Each response completes its request. A disconnection, competing write or device-side change can occur before the next one. The rollback of a later SetRequest does not travel backward through earlier completed exchanges.

Nor does the rule coordinate several agents. “As if simultaneously” compares assignments in one request processed by one responding entity. It does not create a distributed commit across routers, monitors or other devices.

Even the name undoFailed preserves a necessary limit. When rollback itself cannot be completed, the manager must read the effective state and recover from observation. Recording “nothing changed” would assert precisely what the agent could not guarantee.

A lifecycle of bounded claims

RowStatus did not guarantee that a compound configuration would work. It allocated narrower responsibilities. The manager requests creation, supplies values and chooses when to request activation. The agent decides whether it can create the instance, whether information is sufficient, whether values are consistent, whether resources exist, and when abandoned work must be removed. The table definition supplies its edit and expiry policy.

That division produces a sequence of different claims: an action was sent; creation was accepted; the row exists; required information is present; the agent accepted active; the intended service effect occurred. None automatically proves the next.

The row that existed before it was ready was not an embarrassing implementation leak. It was the standardized representation of the middle of a process. SNMP kept its operations small by exposing a bounded lifecycle, not by pretending that a compound configuration was one instantaneous variable.

Sources