摘要

  • RSVP 的 PathErr、ResvErr 和 Notify 仍须携带标准 ERROR_SPEC；使用 33 号错误代码时，消息还必须带有 USER_ERROR_SPEC，否则就是畸形消息。
  • 外层代码只说明详细信息应在何处，企业号、子组织与自定义错误值的完整组合才限定含义；任何后续动作仍需本地授权和独立结果验证。

监控系统收到一条 RSVP 错误。外层 ERROR_SPEC 的代码是 33，界面立刻把它标成“用户自定义错误已接收”。但消息里没有 USER_ERROR_SPEC。没有企业号，没有子组织，没有 16 位错误值，也没有可供人查看的说明。

这不是一条可以靠猜测补全的简化消息。RFC 5284 明确要求：发送 33 号代码时，PathErr、ResvErr 或 Notify 中必须同时包含 USER_ERROR_SPEC；缺少伴随对象就必须按畸形消息处理。外壳指向内容，却不能替代内容。

这个看似细小的规则，是整套控制边界的缩影。协议可以证明某个代码到达，也可以证明某个扩展对象随之到达；接收者还要证明自己解析了完整命名空间、使用了正确版本的私有映射、授权了某项动作，并从独立观测中确认结果。把第一张收据涂成最后一个结论，会让自动化看似顺畅，却失去可追责性。

新对象没有取消旧义务

基础 RSVP 规定 PathErr 与 ResvErr 必须携带 ERROR_SPEC，RSVP-TE 又把这一要求用于 Notify。RFC 5284 选择在这个标准对象旁边增加 USER_ERROR_SPEC，而不是另起一套替代消息。

若已有标准错误代码能够描述条件，自定义对象可以提供额外细节。若没有合适代码，才使用 33 号 User Error Spec；其 0 号子值表示“进一步细节在 User Error Spec 中”。因此，33 号代码是定位符，不是私有错误本身。

这套双层结构让接收者可以分别验证两件事：标准错误上下文是否完整，自定义细节是否存在且结构有效。只记录 33，会把所有私有错误压成一类。只记录自定义数值，则会丢失它伴随的是哪种标准错误语境。

适用消息也有限定。USER_ERROR_SPEC 可以出现在 PathErr、ResvErr 或 Notify 上；若出现在其他消息上，就必须当作畸形处理。ResvConf 虽然含有 ERROR_SPEC，但该处并不承载有意义的错误代码和值，所以扩展并不适用。解析器若为了“兼容”而在任何消息里都接受对象，实际上取消了协议提供的上下文证明。

一条私有错误的主键不是一个数字

对象首先携带由 IANA 分配的 32 位 Private Enterprise Number，然后是 8 位 Sub Org，再后面才是 16 位 User Error Value。组织可以用 Sub Org 为并行开发团队建立独立空间；不需要分割时，该字段应为零。

所以，错误值 9 本身不是可全网解释的标识。企业甲的子组织 2 可以把它定义为资源不足，企业乙的子组织 0 可以把它定义为测试模式不匹配。同一企业的两个团队也可能复用 9。真正的键是企业号、子组织和值的三元组。

IANA 企业号登记保证上层命名空间可以区分，却不会把下面所有私有值自动变成全球标准。它也不认证某条具体 RSVP 消息的发送者，更不会替接收者决定哪项修复安全。消息保护、私有字典版本与本地授权仍是三个独立控制面。

长期证据还应保留解释版本。私有字典会随软件版本演进；今天对数值 9 的定义可能不同于三年前。完整记录至少包括原始对象字节、三元组、应用的映射版本、解释组件、时间和结果。否则，后来的人会用新字典重写旧事件的含义。

194 类对象能穿过“不知道”的节点

USER_ERROR_SPEC 被分配为 Class 194、C-Type 1。194 位于 RSVP 的 192–247 范围：不理解该对象的实现会原样转发它。旧节点因而不必先获得新语义，也能避免把扩展从路径中删除。

原样转发只是一张传输收据。它不能证明节点识别了企业号，不能证明它有私有字典，也不能证明它显示、记录或采纳了错误。目的端能够解释对象，不会追溯性地让所有中间节点都变成理解者。

这正是渐进演进的价值。第一阶段可以只确保对象不丢；第二阶段让部分接收端记录完整三元组；第三阶段安装解释映射；第四阶段才为少数值授权自动动作。每一步都有自己的回退面，不需要为了支持新诊断而一次性更新全网。

重复对象也不能被误当成多数票。RFC 5284 说实现应忽略重复的 USER_ERROR_SPEC，并在继续转发消息时将其原样带走。重复次数是消息形态信号，不是严重度倍增器，更不是多个独立来源的共识。

说明文字不能承担关键操作语义

错误说明使用 UTF-8/Net-Unicode，并以空字节填充到四字节倍数；长度字段不含填充，长度为零也合法。为提高兼容性，标准建议在可行时使用单行、可打印 US-ASCII，但没有把 UTF-8 退化成只准英文。

关键限制是：部分实现可能无法显示某些字符，所以说明只能作为补充，网络运行所需的关键信息应放在数值字段中。不支持 UTF-8 的接收者应按 RFC 5137 对字符进行转义。

这意味着自动化不能靠搜索一句话来选择高风险动作。描述会因版本、语言、标点、转义和显示能力而改变。机器集成点应是带作用域且有版本的数值映射；说明文字服务于人类判断。

日志边界还要面对控制字符和溢出风险。正确做法是同时满足两项义务：保存原始对象作为证据，向终端和日志输出经过安全处理的视图。若直接显示原字节，观察工具会成为攻击面；若只保留清洗后的字符串，原始证据又被改写了。

TLV 的公共语法没有赋予公共含义

对象可以继续携带组织自定义子对象。其外壳是类型—长度—值：Type 与 Length 各占 8 位，总长度包含这两个字段，至少四字节并且是四的倍数。通用解析器因此能安全跳过、保留或转发不认识的子对象。

但 Type 的分配和 Value 的格式仍由企业号与子组织指定。共同语法解决边界识别，私有规范解决语义，本地策略解决权力。通用实现知道下一段从哪里开始，不等于知道这段应该触发什么。

这种“部分互操作”比虚假的全局统一更诚实。标准保证扩展不会破坏基本消息；命名空间指出谁拥有定义；接收者保留是否信任、是否行动的决定。系统若只因对象长得像标准 TLV 就赋予它通用权威，会越过最重要的控制边界。

从收到到恢复，至少还差四张收据

RFC 5284 建议接收实现至少记录企业号、子组织、自定义错误值与错误说明；能够解释内容的实现，应根据报告的错误采取进一步行动。记录与行动是相邻阶段，而不是同义词。

接收之后，系统应分别回答：消息结构是否有效；三元组是否完整保存；哪个映射版本给出了解释；哪个策略授权了什么动作；执行器是否成功；独立信号是否确认原条件改变。任何一步都可能失败，而不否定前一步已经发生。

例如，解析完全正确，动作却因权限不足被拒绝；动作返回成功，路径状态却没有变化；监控变绿，但观测的是缓存而非真实资源。这些不是一个 handled=true 能表达的状态。

更可靠的模型是一张收据图。每条边记录参与者、输入摘要、策略版本、时间与结果。USER_ERROR_SPEC 是图中的证据起点，而不是可以跳过所有授权和验证的远程命令。