摘要

  • 第 01 版草案用只读叶节点描述一套自上而下的 SCHC 变更上限，但这些叶节点本身不承载调用者身份。
  • 每次生效变更都应同时通过主体/请求授权与完整的 SCHC 父子权限链，并保留版本前置条件、验证、对端激活和回滚凭证。

一个控制器收到更新请求。管理通道已经认证，调用者所在组拥有写配置的权利；目标字段又显示 change-tv。界面上于是出现两个绿色标记，任务进入执行队列。

但这两种绿色不是同一种证明。前者说明一个会话可以执行某类管理操作，后者说明某个 Field Descriptor 原则上允许修改 Target Value。它们还没有共同回答：这个主体是否可以在此刻修改这台设备的这个 Context；请求看到的旧规则是否仍是当前规则；另一端能否按同一版本切换；失败时能否恢复。

这不是一宗真实事故，而是根据 2026 年 9 月 29 日提交的 draft-ietf-schc-access-control-01 重构的操作情境。它把一个常被 API 掩盖的问题摆到台面：对象被标记为“可修改”以后，修改权究竟从哪里来？

压缩掉的字节，变成了必须治理的共同知识

RFC 8724 下的 SCHC 依靠共享 Context 节省传输。一个 RuleID 之所以能替代大量头字段与处理信息，是因为压缩端和解压端对同一条 Rule 有共同理解。规则里的 Field Descriptor 包含字段标识、长度、位置、方向、Target Value、Matching Operator 和 Compression/Decompression Action。

这套节省机制同时放大了规则完整性的后果。如果两端给同一 RuleID 赋予不同语义，线上短报文并没有足够信息自行消除分歧。RFC 9363 的安全章节因此警告：错误修改应用 IPv6 地址可能阻断通信或协助窃听；设备只能修改属于自己的规则，而且请求者身份必须被验证。

第 01 版草案处理的是另一半难题。只给整个 YANG 子树一个粗粒度写权限并不够。同一条规则里，Uri-Path 的 Target Value 可能需要变，而应用前缀必须固定。真正的控制单元不是“能否写这个模块”，而是“能否在这个层级执行这一类变化”。

三层权限描述的是上限

草案为 RFC 9363 模型增加只读的 config false 叶节点。ac-modify-set-of-rules 位于规则层，可表示不可变、可修改既有元素，或可增加删除元素。ac-modify-compression-rule 再约束压缩规则内的 Field Description。ac-modify-field 则把字段修改细分为不可变、只改 Target Value，或连同 Matching Operator 与 Compression/Decompression Action 一起改变。

父子关系不能省略。压缩规则层只有在上层允许修改时才生效；字段层只有在两层父权限都放行时才生效。子节点写着允许，不等于可以穿过父节点的禁止。叶节点缺失时，草案明确说相应信息不可修改。

config false 也意味着远端编辑者不能在同一次操作中先给自己发放权限。这是正确的权限方向：请求对象不能制造批准请求的依据。

然而，这些值只描述规则模型所容许的变更形状。它们没有用户名、设备归属、组、凭据、会话、策略版本或委托链。change-tv 是动作与对象，不是法律或技术意义上的主体。

主体来自管理层，而不是字段标签

草案并未否认主体层。它引用 RFC 8341 的 NACM，并说明 NACM 可以让用户或用户组执行特定动作。NACM 将已认证会话关联到用户名和组，按协议操作与数据节点匹配规则，拒绝时返回 access-denied。它还要求一次消息处理期间使用同一套生效规则，避免决策中途换尺。

NETCONF 要求连接被认证，并可通过能力提供 candidate datastore、验证、锁和 rollback-on-error。RESTCONF 把获准的 HTTP 编辑映射到 YANG 数据，借助 entity tag 和 If-Match 拒绝基于过期版本的写入。CORECONF 面向受限设备，以 CoAP 和紧凑编码承载 YANG 管理，同时要求阻止未经授权的读写，并指向 DTLS、OSCORE、ACE OAuth 等安全机制。

这些管理能力不能替代 SCHC 叶节点。NACM 的 CRUDX 可以表达某组有权更新数据节点，却不自然地表达“同一规则里 Uri-Path 的 TV 可改，应用前缀不可改”。反过来，change-tv 也无法说明哪一个已认证会话属于获准的组。

安全条件必须是相与，而非相或：

这个主体可以执行这个请求，并且这个 SCHC 元素可以发生这种改变。

任何一侧被当作另一侧的替代品，权限都会悄悄膨胀。要么广泛的管理角色吞掉字段边界，要么一个宽松字段标签变成任何到达端点的人都能使用的无记名票据。

写入成功不是协议切换成功

当前草案没有说明谁配置这些只读叶、权限如何推导、撤销何时影响排队请求，也没有建立主体与某个 Context、Set of Rules 或 RuleID 的所有权绑定。它没有规定版本前置条件、并发写入冲突、多字段原子性、激活协调、对端确认、审计收据或回滚。

这不能被解读为部署无法提供这些功能。NETCONF 和 RESTCONF 已经提供若干事务工具，系统也可以加入自己的生命周期控制。准确的结论只是：第 01 版的访问叶不是完整的变更治理协议。

共享 Context 使这一区别尤其重要。数据库可以接受语法和权限都正确的编辑，而另一端仍持有旧 Rule。此时“写操作成功”只描述管理事务，不描述协议转换。领导者需要另一个激活事实：哪个版本何时成为权威、哪些对端完成兼容确认、观察到什么运行结果？

RESTCONF 的 entity tag 可用来建立现实的前置条件：读取当前版本，提交 If-Match，发现其他写者抢先改变资源便拒绝。NETCONF 的锁与 candidate 配置提供另一条路径。但即使并发控制完美，也还没有决定 SCHC 两端何时使用新语义。事务一致性与协议同步相邻，却不相同。

草案中的空白就是风险信息

第 01 版是活跃工作组 Internet-Draft，页眉标注 Standards Track，但还不是 RFC。文本的未完成状态非常直白：Terminology 留着 ToDo；Security Considerations 与 IANA Considerations 仍是 TBD；YANG 模块的 revision 还是 2023 年，并残留 compound-ack 与 RFC YYYY 的无关说明；字段权限枚举的描述写着 Reserved slot number。

读者不应嘲讽这些痕迹，也不应自行替规范补齐。它们说明自动化、采购与合规此时都不能把命名、语义和安全组合当成冻结事实。

2026 年 7 月的 SCHC architecture 草案同样强调 Context 完整性、认证授权、变更审计与恢复已知良好版本，同时承认生命周期和管理章节仍待发展。现有一手资料没有证明生产部署范围、互通结果、事故发生率或性能。

一张可以经得住争议的变更凭证

每次重要变更至少应保存：

  1. 已认证主体、用户组、会话和传输保护；
  2. 管理协议、操作、目标 Context、Set of Rules 与 RuleID；
  3. 旧版本或 entity tag，以及精确的前后值；
  4. 从父到子的全部 SCHC 权限叶；
  5. 作出主体授权时采用的 NACM 或等价策略版本；
  6. 验证、事务和冲突检查结果；
  7. 激活时间、涉及对端与兼容证据；
  8. 运行观察、责任人、回滚点与回滚测试。

这就是最小权限在工程实践中的完整形态。管理层认证并授权主体，SCHC 模型限制对象，事务层保证一次编辑的连贯性，协议运营者承担激活及其后果。不能因为它们出现在同一个 API 调用里，就让某一层借走另一层的权力。

Sources