摘要

  • draft-toutain-t2trg-coreconf-m2m-01 提议把紧凑的 YANG/SID 数据模型投影到 ontology、FROST 与 MCP 工具，让 agent 能够定位设备、读取传感器或配置控制项。
  • 工具定义、正确 SID、受保护的 CoAP 通道与成功响应分别证明不同环节；其中任何一个都不能单独证明调用者有权驱动执行器，也不能证明目标物理状态已经出现。
  • 可辩护的执行收据必须绑定模型版本、身份映射、请求主体、授权策略、批准、请求与重试、设备侧验证、实际动作及独立回读。

“不需要设备专用翻译层”听上去像一条没有中间人的直线：agent 选择工具，MCP server 找到 SID，CORECONF 把命令送进设备。问题是，翻译代码可以消失，解释权却不会消失。

谁把 FROST 中的 Thing 关联到某个 endpoint？谁认定 10000001 仍然代表当前的温度传感器？谁决定整数应按几位小数还原、单位是摄氏度还是别的量？谁把“可写 quantity”解释为允许某个 agent 在此刻改变执行器？这些判断都发生在所谓直线之中。

截至 2026 年 10 月 2 日，IETF Datatracker 把 CORECONF for Machine-to-Machine Communication 修订版 01 列为活跃的个人 Internet-Draft，更新时间为 9 月 16 日。正文同日成稿，拟定 Informational，失效日为 2027 年 3 月 20 日。它没有 RFC stream、负责 AD 或 telechat；Datatracker 明确说明个人稿件不代表 IETF 背书，在标准流程中没有正式地位。T2TRG 邮件列表是讨论场所，并不等于 IRTF 已采纳这份文稿。

同一天显示的 YANG 验证结果是 19 个 error 与 8 个 warning，包括 revision 缺 reference、节点或 grouping 缺 description、语句顺序不符合 canonical order，以及 config false bootstrap 不在可访问树中的警告。这些是当前提交件的成熟度证据，不是安全评分，也不能用来断言某个实现已经失败。

共同语义降低成本，也集中解释权

草案用 YANG 表达结构，用 CBOR 压缩载荷，用 CoAP 交换消息，再用 YANG SID 把长标识符压成数字。模型把 sensor 与 actuator 统称为 transducer；它保存当前 quantity、时间戳来源、累计统计和通知参数，并提供读取、重置、配置与订阅动作。

修订版 01 新增了 SOSA、SensorThings 与 MCP 的桥接。提议中的 coreconf-m2m MCP server 面向实时设备，frost-sensorthings server 面向 FROST 历史与关系数据。Rennes 示例先在 FROST 中找到 Thing，再沿 Datastream 取得 sensor SID 与 precision，随后对设备做 live read，并把结果写回 Observation。

这套设计的价值很具体：同一模型可以替代许多一次性序列化适配器。但 MCP server 仍在做高风险解释。它从数据库解析 hostname、CoAP endpoint、transducer identity、instance SID、target SID、unit 与 precision，然后生成协议请求。数据库的新旧、映射的来源、覆盖值与默认值，都进入了实际控制链。

错误 endpoint 可以把正确命令送到错误设备；重用的 identity 可以把新名称套在旧硬件上；错误 precision 会把合法整数变成貌似合理的错误物理量；把 category 从 sensor 改成 actuator 会扩大可调用表面。任何一步都不一定产生语法错误。

因此，投影收据至少要保存 YANG module 与 revision、feature 与 deviation、SID 文件及 private translation、设备与 transducer identity、bootstrap generation、endpoint、unit、precision、category、control type、method、path、target SID，以及 FROST 记录的版本、来源和新鲜度。工具名称只是一层用户界面。

可发现的 Control 不是权限清单

ccm2m:Control 把操作写得很清楚：read-single 读取当前量，read-stat 读取统计，reset-stat 或 reset-all-stat 清除统计，setup-history 配置历史，subscribe-history 开始观察，instant-write 写执行器。停止订阅则属于 CoAP Observe 的状态，不是另一个 SID 控件。

这种拆分很有价值，因为它没有把配置、开始与停止混成一件事。但 control graph 没有说明哪一个 principal 有权在何时调用。它也不携带批准人、业务目的、允许范围、维护窗口、重试上限、安全联锁或紧急停止条件。

不能把这个缺口误写成“CORECONF 没有授权”。底层 CORECONF 修订版 21 明确要求 server 阻止未授权用户读取或写入资源，并规定当 client 无权操作 data node、datastore、RPC、action 或 event stream 时返回 4.01 Unauthorized；安全章节还要求选择适当的认证与授权机制。

当前 2026-07-28 MCP 规范同样没有把 tool discovery 当作普遍许可。tools/list 的结果可以根据每次请求携带的 authorization 改变；server 必须验证输入、实施 access control 与 rate limit；client 应对敏感操作请求确认、展示参数、验证结果并保留审计。tool annotation 在 server 未受信任时也不可信。

真正困难的是跨层绑定。执行记录需要把 MCP server 身份、tool definition hash、请求 client、认证 principal、credential audience 与 scope、policy version、人工或自动批准、目标资源与参数边界，连到 CORECONF 的授权决定。只记“某工具被调用”，无法回答谁把权限委托给谁。

传输受保护，不代表执行已成立

所选草案要求 CORECONF over CoAP 使用 DTLS 或 OSCORE。这能按部署 profile 保护消息，却不会替设施所有者决定一台泵能否在维护期内升速。加密能够完整传递一条越权命令；认证能够识别一个被错误授予 scope 的主体。

CORECONF 区分 Unauthorized、Method Not Allowed、Not Found、模型约束和其他处理错误。成功响应说明请求在该协议层被处理。它不测量阀门位置、电机转速、温度或压力，也不说明状态保持了多久。

草案用一台虚构水泵说明 instant-write：把转速写为 1500 rpm。因为示例模块里并不存在这台泵，它的 identity SID 使用 PPPPPP 占位；quantity 的结构 SID 则是真实定义。SOSA Actuation 记录写入值与 client 发出命令的时间。正文明确说，这是一条 command，不是 observation。

这一点比“成功”按钮重要。命令记录不是转速表。后续回读必须说明 sensor 身份、校准、unit、precision、timestamp source 与因果时间窗。如果 gateway 从刚写入的缓存行生成确认，它只是把意图复述了一遍。

可辩护的链条应分别留下：工具调用；用户或策略意图；principal 与授权；受保护请求；应用验证；持久化变更或 action 启动；设备本地联锁；物理动作；独立或适当隔离的测量；状态持续时间；冲突处理与回滚。链条可以在任何一步停止，但 UI 必须说清它停在哪里。

共享通知参数暴露真实影响范围

通知配置是草案里最容易被忽略的控制面。history 的 step、precision、max-samples、time-period、encoding、max-payload，以及 alert 的阈值、hysteresis、dampening 与 confirmable cadence 都可写。它们由同一个 transducer 的全部观察共享；在通知已 active 时修改，会立即影响所有 client，而不只影响发起者。

start_history_notify 因而不是纯粹的个人订阅。它先 iPATCH 配置，再 FETCH+Observe。对调用者看似“为我开始历史”，对其他观察者却可能改变采样节奏、编码或确认频率。active 只表示至少有人观察，不列出观察者、目的或同意状态。

安全工具应当显示共享 scope，读取旧版本与旧值，使用 precondition 或冲突规则，记录 before/after，并列出受影响观察者。允许读取当前温度，不等于允许重配所有人的通知；允许查询 FROST，也不等于允许修改 live controller 依赖的身份映射。

NON 消息把不确定性上移到应用

该 profile 要求 FETCH 与 iPATCH 使用 Non-Confirmable CoAP。对于低功耗链路，这可以避免不合适的默认重传；代价是 timeout、retry 与 idempotency 必须由应用承担。

响应缺失时，MCP server 不知道请求未到、设备已执行但回复丢失，还是动作仍在进行。重复设置一个目标值与重复执行有副作用的 action 不是同一风险。收据要带 request identity、CoAP token、payload hash、attempt、timeout policy、duplicate handling，以及后续读取。

Confirmable notification 的 ACK 也只证明 CoAP peer 收到消息。它不证明 FROST 已持久化、agent 已考虑、值班人员已看到，或物理异常已经解除。受限网络越节省字节，证据类型越不能含糊。

时间与尺度决定回读能否成立

bootstrap 可以提供 reference epoch、uptime 与 minimal-step，但 reference epoch 可能缺失。quantity 的 timestamp 可能来自 source，也可能是 receiver 到达时补上的；history 的时间还可能从接收时刻与 step 反推。发令时间、固件接受时间、物理动作时间与数据库写入时间不能互换。

原始整数只有结合 identity、unit 与 precision 才成为物理量。超过 minimal-step 的轮询只会耗电，不会产生更新鲜的样本。后置条件必须保存模型版本、尺度、校准、时间来源、时钟质量与 freshness。

同理，YANG 的 19/8 验证结果只是模型收据。它提示当前 revision 有待修复；未来变为零也只说明所选 validator 接受了它，不能证明 authorization 正确、互通已经发生或泵轴已经转动。