摘要

  • RFC 3179 在 SNMP Agent 的 Script MIB 与具体语言运行时之间定义 SMX。231 可以确认脚本进入 running、暂停或恢复后的状态，却不代表执行已经结束。
  • 532/533、536/537 与 538 分别承载中间结果、错误与终止。错误还分致命和非致命，任何单个代码都不能替整段执行历史下结论。
  • 终止和结果记录仍不是网络效果。调用者必须解释结果字节，并从受管对象的权威表面独立回读，才能判断目标是否实现。

“已运行”是一项准确但有限的事实

RFC 3179 于 2001 年 10 月发布，题为 Script MIB Extensibility Protocol Version 1.1。它的状态是 Experimental，正文明确说明这不是任何意义上的互联网标准。它记录了一种细致的机制，却没有因此证明现实中的产品部署、运营者采用或互操作成绩。

相邻的 RFC 3165 定义 Script MIB。管理者可以通过 SNMP 认识脚本、装载代码、提供参数、启动多个实例、控制运行并读取结果。可是语言各不相同，把 Java、Tcl 或其他执行引擎全塞进 Agent，会让统一管理接口与具体语言绑定。SMX 的做法是在两者之间建立一套小协议，让 Script MIB 保持语言无关，让运行时专注执行。

分离也带来了证据边界。Agent 知道管理者请求了什么、MIB 对象怎样变化；运行时知道代码能否在所选安全配置下启动，以及实例处于什么状态。两者之间的回复只能证明这条关系上的一个转移。它没有观察脚本返回值的业务含义，更没有观察路由器、服务器或服务最终发生什么。

连接建立并完成 hello 后，SMX 可以传送 start、suspend、resume、abort、status 等命令。三位数字代码把成功、失败和异步事件分开。编码越简洁，越需要守住语义：一个代码不是整项任务的结论，而是某一方对某一时刻的收据。

start 最能说明问题。运行时检查语法、脚本与安全配置，创建实例，并在它达到 running 后返回 231。这个回复不只是“网络收到了一串字节”；它确认命令已被解释，而且运行实例真实存在。

然而任务才刚开始。脚本可能继续计算、等待资源、输出阶段性结果、遇到可恢复错误、永久卡住或异常终止。它也可能正常结束，却返回调用者无法解释的值。231 对“启动是否达到运行状态”给出了强证据，对“工作是否完成”则没有发言权。

暂停和恢复也使用这条原则。suspend 在实例已经或成功进入暂停状态时返回 231；resume 在重新达到 running 后返回 231；status 报告运行时看到的状态；abort 则在终止实例或发现它已经中止后返回 232。每一个都关闭一项控制动作，没有一个可以代替网络结果。

中间结果不能自行升级为最终答案

RFC 3179 给异步输出安排了单独编号。532 传递中间结果；533 除传递结果外，还要求通过 Script MIB 产生 smScriptResult 通知。前者发生在运行时与 Agent 的连接中，后者把事件投射到更外层的管理界面。这两件事不能因为内容相同就被视为同一条送达证明。

“中间”一词保留了尚未结束的时间。一段诊断脚本可能先报告已经检查的接口，再在后续接口处失败；一段变更脚本可能完成第一步，却无法提交第二步。第一个可读值可以完全真实，同时仍不足以描述整项任务。如果后续消息消失，不能把沉默当作最终成功。

RFC 3165 还把语义责任留给调用者。参数和直接结果都是 OCTET STRING；Script MIB 不知道其中的字节代表计数、状态、文本还是专用编码。调用者必须知道格式及意义。复杂结果可以通过另一组 MIB 对象暴露，超大结果也可以只返回 URL。此时 URL 只是位置声明，下载、完整性验证、解析与采用仍是不同事件。

已结束脚本的历史可以保留，方便管理者稍后取回结果。这支持离线工作，却引入了保存期限：表满时，条目会按老化控制被移除。“曾经执行完”与“审计时仍能取得结果”因此不是同一句话。没有收集收据的历史条目随时可能成为无法解释的空壳。

错误可能发生，而执行仍继续

536 用于报告错误，537 用于报告还应触发 smScriptException 通知的错误。两者都可能描述致命或非致命情况。非致命错误之后脚本继续执行；致命错误之后才会出现终止。

于是观察者至少要保存三项事实：运行时是否发生错误，错误是否被投射到管理界面，实例后来是否结束。通知没有被接收，不等于运行时没有错误；错误已出现，也不等于脚本已经停下。若只保留最终颜色，短暂故障、继续运行与致命失败会落进同一个格子。

版本 1.1 新增 538，专门表示运行实例终止，并弃用原来的正常终止 534 与异常终止 535。新的组合让结果或错误先按自身含义发送，再由 538 明确关闭执行区间。终止事件不再被迫同时携带“为何结束”和“产出什么”两种责任。

538 仍然不是业务结论。它只说明运行时认为实例已经结束。调用者还要把它与脚本版本、参数、之前的结果和错误相连，依据正确模式解释字节。若要证明网络效果，还必须读取更远的一层：配置权威库、运行状态、计数器、流量、可达性或与任务相符的服务观测。

安全配置限制能力，不保证正确性

远程脚本意味着委托权力。RFC 3179 建议把 Script MIB 的 launch owner 映射到操作系统安全配置和运行时安全配置。操作系统可以建立受限进程环境，安全解释器或虚拟机则约束语言层能力。这些措施回答“这次执行可以触碰什么”。

它们不回答“算法是否正确”。最小权限脚本也会算错；正确脚本也会接收错误目标；合法所有者也会启动旧版本；运行时正常终止后，远端设备仍可能拒绝变更。授权、执行质量和外部效果必须分别记录。

本地脚本存储是另一个保管点。RFC 要求只有 SNMP Agent 能写入该区域，否则攻击者可能替换文件，让高权限运行时执行任意代码。管理表中的友好名称不是代码身份证明。审计记录需要把名称、实际字节、装载时刻和执行实例绑定起来。

传输变化体现了同样的思路。SMX 1.1 保留 TCP，并增加双向 pipe 作为首选方式，因为 1.0 把共享秘密放进操作系统环境变量，产生泄露风险。pipe 消除了这一种暴露路径，却不会自动证明本地权限、进程身份、文件保管或 SNMP 访问决定全部正确。

后来的 RFC 3411、3414、3415 分别提供 SNMPv3 架构、基于用户的安全模型和基于视图的访问控制背景。它们不能被倒写成 SMX 自带的安全功能，也不能证明某个假想部署使用了这些保护。管理对象访问获准，也不等于脚本随后产生的每个外部作用都获准。

真正的执行账本在 231 之前开始，在 538 之后结束

完整记录首先保存不可变脚本版本、所有者、参数、目标、安全配置与请求时刻。随后记录实例标识及达到 running 的 231，并按顺序保存每个 532/533、每个带致命属性的 536/537，最后保存 538。历史条目保存多久、谁在何时取走结果，也属于同一证据链。

接下来是解释收据。结果消费者要声明用哪个模式理解 OCTET STRING。若结果是一条 URL，就要分开记录引用、成功下载、下载对象完整性与解析。若系统应产生通知，就要分开记录生成和接收。

最后才是目标系统的回答。配置任务需要从权威配置面回读，必要时还要验证运行态；诊断任务需要观测窗口与分母；流量变更需要后续计数器或数据包证据。运行时协议看不到这些事实，自然不能替它们出具证明。

RFC 3179 的历史价值不在于把网络管理变成脚本，而在于拒绝让一个“成功”承担所有语义。命令处理、运行状态、中间输出、错误与终止有不同消息；结果意义属于调用者，网络现实属于目标。自动化只有在每张收据不越权时才真正可审计。

来源与边界

RFC 3179 的状态、命令流程、异步回复、传输与安全考虑见 RFC 3179 文本、RFC Editor 记录、HTML 版本、IETF 历史与勘误检索。Script MIB 的相邻模型、结果语义和执行历史来自 RFC 3165 文本、记录与 HTML 版本。被替代版本的比较以 RFC 2593 文本和记录为限。

后续 SNMP 背景来自 SNMP 架构、基于用户的安全模型与基于视图的访问控制模型。命令、状态、证据与结果的分析分层受 Lu Heng 关于运行代码优先、现实层次和最小初始规范的文章启发。16 个 URL 于 2026 年 10 月 2 日在 Asia/Shanghai 冻结。

这些材料证明协议设计与文档状态，不证明部署。它们没有确立任何现实实现、运营者、脚本、设备、安全配置、攻击、节省成本、网络变更或服务结果。证据链结论是 Sofia Ren 的编辑分析，并非 RFC 作者或所引机构的主张。