Summary

  • SNMP RowStatus made three observable conditions distinct: a conceptual row may exist while missing required information, may be complete but deliberately out of service, or may be active and available to the managed device.
  • createAndGo, createAndWait and destroy are requests, not states returned by a GET. The manager expresses intent, while the agent applies the MIB's rules and decides whether the requested transition is admissible.

A table was an agreement, not a database

The earliest management information bases looked comfortably tabular. A manager addressed an object identifier, added an instance index and read or wrote one column in what the standards called a conceptual row. The visual analogy invited a dangerous assumption: if the cells existed, the configuration existed in every meaningful sense.

RFC 1212, published in 1991, was more cautious. It described tables and rows as conventions imposed by applications. SNMP did not carry a relational model that automatically created a complete row, enforced dependencies or made a half-built entry safe to use. A MIB could define a status integer for deletion, an agent could accept a SetRequest naming instances that did not yet exist, and defaults could fill omitted columns. But each MIB still had to explain what those acts meant.

That looseness was tolerable while most tables were observations produced by the device. It became a coordination problem when several management stations could create configuration. Which write acquired the chosen index? When did an incomplete row become real? Could a second manager see it? When was the managed device allowed to act on it?

RMON exposed the unfinished row

The Remote Network Monitoring MIB in RFC 1271 supplied an important precursor. Its EntryStatus distinguished a request to create an entry from an entry underCreation, a valid entry and an invalid one. A manager could reserve a row, populate it and only then make it valid. If two managers tried to create the same indexed row, only the first successful request won; the other received an error.

RMON also attached an owner string so management stations could identify the creator of a resource and cooperate. The document stated the limit plainly: ownership information was not access control. An uncooperative manager could still alter or delete an entry. Attribution helped coordination, but it did not manufacture authority.

This distinction matters because configuration systems often overread labels. A creator field is not authentication. A row's presence is not readiness. A status value is useful only within the exact transition rules that give it meaning.

Six values divided into states and actions

SNMPv2 standardized the broader solution in RFC 1443. The current definition in RFC 2579 retains six RowStatus values, but they do not describe six states of equal kind.

Three values can be observed. active(1) means that the row is available for use by the managed device. notInService(2) means that it exists and is unavailable, although the agent has enough information to attempt activation. That value does not promise that the row is internally consistent, that resources are available or that activation will succeed under the device's present condition. notReady(3) means that the row exists but one or more required column instances are missing.

Three other values are actions supplied in a SetRequest. createAndGo(4) asks the agent to create and activate a new row. createAndWait(5) asks it to create the row without placing it in service. destroy(6) asks it to remove every instance belonging to the row.

A GET never returns createAndGo, createAndWait or destroy. It returns only active, notInService or notReady for a row that exists. Nor may a manager set notReady; that is the agent's report about missing information. The vocabulary therefore keeps command and evidence from occupying the same value.

Create and go meant all the way or not at all

One-step creation is attractive because it compresses a workflow into one request. The manager chooses an unused instance identifier and sends the required column values together with RowStatus=createAndGo. Defaults supplied by the agent may complete the set.

The result is deliberately severe. If the agent has sufficient information to make the row available, it creates the row and the readable status immediately becomes active. If information is insufficient, the operation fails with inconsistentValue and the row is not created.

There is no standardized half-row left behind for the manager to repair. A failed response does not mean “draft saved.” The manager must find the missing requirement and retry, or choose staged creation if the agent supports it. One message can combine creation and activation, but only because failure preserves the boundary.

Create and wait made incompleteness visible

createAndWait serves a different operational need. On success, the row exists but remains unavailable to the managed device. If required information is absent, a read shows notReady. Once the missing column instances have been supplied, the agent can move the row to notInService: complete enough to attempt activation, yet still deliberately inactive.

The manager then writes active. The agent may accept the transition or reject it with inconsistentValue. Completion is not the same as admissibility under current resources and state.

An agent is also allowed not to support this negotiated path. It may answer wrongValue to createAndWait and require a complete one-request creation instead. The state machine is common, but the MIB and agent still define the supported surface.

Rows left unavailable consume resources. RFC 2579 therefore requires an agent to detect entries that remain notReady or notInService for an abnormally long period and remove them. The MIB description should define the interval; when it does not, the RFC suggests roughly five minutes, including human think time. That is a suggested default, not evidence of any vendor's actual timer.

The MIB description carried the missing law

RowStatus does not answer every question. Some tables permit column changes while a row is active. Others require the row to be taken out of service first. An agent may refuse suspension because the row is in use, and it may refuse deletion for the same reason.

The status column's DESCRIPTION must say which values are required before activation and whether other columns can be modified while active. RFC 4181 later turned these into explicit authoring duties. A dynamic, manager-created table should normally have one read-create RowStatus column. Its MIB must also explain persistence, any StorageType behavior, conditions under which the agent itself creates or removes rows and the exact modification rules.

The textual convention thus standardizes a grammar without centralizing all policy. It gives managers a common way to request transitions, while each MIB declares what a valid row means for its subject.

One SetRequest had bounded atomic meaning

Creation often sends several column values and the RowStatus change together. RFC 3416 defines SetRequest processing conceptually in two phases: validate the variable bindings, then alter them if validation succeeds. Assignments occur as if simultaneously with the other assignments in that same request.

If an alteration fails, the entity attempts to undo the others and returns commitFailed; if it cannot undo everything, it returns undoFailed. The existence of the latter code is an important warning against turning “atomic” into mythology.

The guarantee is local to one request processed by one SNMP entity. It is not a transaction across routers, not a durable commit protocol, not a distributed lock and not proof that an external data plane now behaves as intended. A successful response establishes a bounded management fact. Persistence after restart and functional effect require separate evidence.

Existence stopped pretending to be operation

RowStatus endured because it named a problem much larger than table syntax. Distributed configuration crosses several authorities. The manager owns the desired change. The MIB owns the public contract. The agent validates what can be represented and activated. The running device supplies the final operational reality.

Collapsing those layers produces misleading certainty. A visible row may still be notReady. A complete row may still be notInService. An activation request may still fail. An active value may survive only in volatile storage or may not prove that traffic is flowing. Each observation is useful precisely because it does not claim more.

Sources and limits

RFC 1212 and RFC 1271 establish the pre-RowStatus conventions and RMON precursor. RFC 1443 and RFC 2579 define the six-value lifecycle. RFC 3416 defines SetRequest processing, while RFC 4181 records later MIB-authoring practice. These sources do not establish modern deployment share, product conformance, security policy, one universal cleanup interval or data-plane success. Reading RowStatus as a disciplined separation of intent, readiness and operation is an inference from those mechanisms.