Summary

  • RFC 3179 placed a small protocol between an SNMP agent’s Script MIB and language-specific runtime systems. A 231 reply could prove that a command reached a running, suspended or resumed state; it did not say that the script had finished.
  • Intermediate results, non-fatal and fatal errors, termination and retained history had different messages and different owners. A collector that reduced them to “success” destroyed the sequence needed to diagnose incomplete automation.
  • Even a clean termination and a stored result remained short of the final claim. The invoker still had to understand the result bytes, and an independent observation had to show whether the intended managed-network effect occurred.

A management interface stopped at the runtime boundary

In October 2001, RFC 3179 described version 1.1 of the Script MIB Extensibility Protocol, or SMX. Its status was Experimental. The memo explicitly said it did not specify an Internet standard. That boundary matters because the document was precise about a mechanism without demonstrating its adoption, interoperability in a named network or success in a deployed product.

The mechanism sat beside RFC 3165, the standards-track Script MIB. The MIB gave an SNMP manager a language-independent surface for installing scripts, supplying arguments, launching instances, controlling execution and collecting results. SMX addressed another problem: the agent implementing that MIB should not have to contain every language engine. A Java runtime, a Tcl interpreter or another execution system could live in a separate process and speak a common protocol to the agent.

That split made extensibility practical. It also created two administrative realities. The SNMP agent knew what a manager requested and what the Script MIB exposed. The runtime system knew whether code could be loaded, started, suspended, resumed, aborted or queried. A reply crossing between them was evidence about that boundary. It was not automatically evidence about everything the script was supposed to accomplish beyond it.

SMX began with connection establishment and a hello exchange. It then defined commands including start, suspend, resume, abort and status. Replies used three-digit codes whose first digit separated success, failure and asynchronous notification families. The compact grammar was useful because it prevented prose from hiding state. But a code was only useful if its scope remained intact.

Reply 231 closed a command, not an execution

The start procedure is the cleanest example. The runtime checked the command syntax, the script and its security profile. If the request could proceed, it created the running script and sent a 231 reply after the script reached the running state. If the request was still being processed, the reply waited for that state. If the launch failed, a different code reported the failure.

That was a strong acknowledgement. It was stronger than “bytes arrived at a socket.” It meant that the runtime had interpreted the request and established a running instance. Yet the code did not mean “the management task is complete.” A script could run for seconds or hours. It could produce intermediate observations, encounter a recoverable error, terminate fatally or wait indefinitely. It could also finish normally while producing an answer whose format or meaning the caller misunderstood.

The same boundary applied to other commands. For suspend, a 231 reply followed the suspended state or reported that the script was already suspended. For resume, it followed return to running or reported that the instance was already there. A status reply described the observed state. An abort produced 232 after the abort or when the instance was already aborted. Each reply closed a control operation. None certified the script’s intended external effect.

This distinction is easy to lose in modern automation because dashboards often prefer one status field. “Accepted,” “running,” “completed” and “effective” become stages of one colour rather than separate claims. RFC 3179’s message flow resisted that compression. The runtime reply had an identifiable producer, an identifiable command and a bounded meaning. A later event was required to say something later.

Results could arrive before the ending

Version 1.1 gave asynchronous evidence its own vocabulary. Reply 532 carried an intermediate result. Reply 533 carried an intermediate result that should also cause an smScriptResult notification through the Script MIB. The difference separated data travelling within the runtime-agent protocol from a management notification exposed beyond that connection.

An intermediate result did not end the script. That sounds obvious, but it is operationally important. A monitoring script might emit a partial count before completing a scan. A remediation script might report one step before attempting the next. Treating the first payload as a final answer would erase the remaining execution interval. Treating silence after that payload as success would erase the possibility that the process stalled.

RFC 3165 made the result boundary wider. Direct script arguments and the single direct result were OCTET STRING values. The invoker had to understand their format and semantics. A script could expose complex results through another MIB or return a URL for output too large for convenient carriage. In those cases, the first receipt proved even less: a URL proved where output was said to reside, not that the caller retrieved, parsed or trusted it.

The Script MIB could keep a history of finished executions for later collection. That supported offline operation, but history was not timeless. Aging controls determined how entries left a full table. Evidence therefore had a retention surface as well as an execution surface. If a manager asked too late, the control system might honestly know that something once ran while no longer holding the result needed to judge it.

An error was not always a termination

RFC 3179 also separated error from ending. Reply 536 reported an error. Reply 537 reported an error that should cause an smScriptException notification. Either error could be fatal or non-fatal. A non-fatal error allowed the script to continue. A fatal one ended execution and was followed by a termination reply.

This gave an observer three questions instead of one. Did an error occur? Was it exposed through the wider management interface? Did it terminate the running instance? A log entry answering the first question could not answer the third. A notification answering the second could be lost or delayed without changing the runtime’s actual state. The sequence of evidence mattered more than the presence of the word “error.”

Version 1.1 sharpened the terminal event by adding reply 538 for termination. It deprecated the older 534 “normal termination” and 535 “abnormal termination” replies. The newer structure allowed result or error evidence to travel through its own messages, followed by one explicit termination event. That change reduced the temptation to make a single terminal label carry both output and ending semantics.

Even 538 was not a business verdict. It proved that the runtime considered the instance terminated. To determine whether the termination was useful, the invoker still needed the preceding result or error, the arguments and script identity, and the semantics of the returned bytes. To determine whether the network changed as intended, it needed evidence from the managed object: configuration readback, counters, traffic behaviour, reachability or another observation appropriate to the task.

Security profiles did not make code correct

Delegated scripting also moved authority. RFC 3179 proposed mapping the Script MIB’s launch owner to an operating-system security profile and a runtime-system profile. The operating system could construct a restricted process environment; a safe interpreter or virtual machine could enforce language-specific limits. Those were meaningful controls because remotely selected code might otherwise inherit privileges far beyond its task.

But a security profile answered “what may this execution touch?” It did not answer “is the script correct?” A tightly confined script could compute a wrong result. A correctly written script could receive the wrong arguments. A valid owner could launch the wrong version. A normal termination could leave the intended device unchanged because the target rejected a request outside the runtime.

Local script storage was another custody point. The memo warned that only the SNMP agent should be able to write files in the local storage area. If another party could alter them, the runtime might execute arbitrary code with special privileges. The administrative script name therefore needed a verifiable mapping to the bytes actually executed, not merely a familiar label in a table.

The transport changed for the same reason. SMX 1.1 retained TCP and added a bidirectional pipe as the preferred mapping. Version 1.0 had passed a shared secret through an operating-system environment variable, where exposure created a security risk. A pipe avoided that particular mechanism. It did not make the entire execution trustworthy by itself. File permissions, process identity, endpoint custody and the surrounding SNMP access decision still had to agree.

Later SNMPv3 architecture, user-based security and view-based access control provide relevant context for authentication and authorization. They do not prove that a particular SMX connection used them, that the caller was entitled to launch the script or that the script’s downstream action stayed inside the authorized view. Transport protection, launch authority and task outcome remain separate surfaces.

The useful ledger had more than one success field

An auditable execution begins before 231. It identifies the script bytes or immutable version, the owner, arguments, target, requested profile and launch time. It records the runtime instance identifier and the reply that established running. It preserves every 532 or 533 result in order, every 536 or 537 error with fatality, and the 538 termination event. It then links the retained Script MIB history entry to what the invoker collected.

After that comes interpretation. The invoker must say what the OCTET STRING meant and which schema or script version supplied that meaning. If the result was a URL, the ledger must distinguish the reference from a successful retrieval and the retrieved object from a valid interpretation. If an SNMP notification was expected, the record must distinguish generation from delivery to a receiver.

Only then should the system attach evidence of the managed-network outcome. A configuration task needs readback from the authoritative configuration surface and, where relevant, evidence that the running state changed. A diagnostic task needs the observation window and denominator. A traffic intervention needs later counters or packet observations. A command receipt cannot fill those spaces after the fact.

RFC 3179’s historical value lies in this choreography. It did not promise that scripts made management autonomous or infallible. It assigned different messages to request processing, execution state, intermediate output, error and termination. The protocol ended at a runtime boundary and left result meaning to the invoker. That modesty remains useful: automation becomes accountable when every receipt proves one transition, and no receipt is promoted into the outcome it did not observe.

Sources and limits

RFC 3179's protocol, status, procedures, asynchronous replies, transport mappings and security considerations are documented in the RFC 3179 text, RFC Editor record, HTML edition, IETF history and errata query. The adjoining Script MIB model, result semantics and retained execution history come from the RFC 3165 text, record and HTML edition. Version comparison is bounded by the obsoleted RFC 2593 text and record.

Later SNMP context comes from the SNMP architecture, User-based Security Model and View-based Access Control Model. The analytical separation of command, state, evidence and outcome is informed by Lu Heng's essays on running-code primacy, reality layers and minimum initial specification. The sixteen-source set was frozen on 2 October 2026 in Asia/Shanghai.

These records prove protocol design and status, not adoption or outcome. They identify no present implementation, operator, script, managed device, security profile, attack, error rate, saved labour, network change or service result. Reply codes are interpreted only within their specified state transitions. The final evidence-chain analysis is Sofia Ren's editorial reading, not a claim made by the RFC authors or cited institutions.