摘要

  • 10月26日，CZ.NIC的BIRD开发负责人Maria Matejka在RIPE 93梳理了NETCONF/XML、RESTCONF/JSON和CORECONF/CBOR。
  • 她的YANG转换提案给出具体例子：JSON里的"+3"原是字符串，经过XML后可能被重新解释为数字。

这个加号过关时没改名字，却丢了证件。JSON里，"+3"外面的引号说明它是文本。经过XML中转，字符还在，类型线索却可能不见。下一台设备给它重新发证，发成了数字。网络配置里，谁在关口盖章，谁就握着一部分决定权。

10月26日，在RIPE 93的报告中，CZ.NIC的BIRD开发负责人Maria Matejka展示了管理接口的“动物园”。原始幻灯片依次看NETCONF与XML、RESTCONF与JSON，再看CORECONF与CBOR。YANG定义数据模型，三套编码却有不同的类型表达方式。设备多开一扇门，自动化工具多一条路，也多一道解释字段的关口。

Matejka在3月提出的个人草案把麻烦写得很具体。某个YANG字段允许int32或string。输入JSON为"item": "+3"，按RFC 7951应当选字符串。XML载着+3继续走，却没有JSON引号传递的类型提示。另一端解读联合类型时，可能选中整数分支。字节看着熟，配置含义已经换了抽屉。

这让转换代理承担的职责超过“搬运”。草案要求依YANG模型解释输入、选合适的输出表示、验证数值，并做概念上的往返检查；类型被重新解释时提出警告，必要时带上原始类型标注。IETF状态页显示，这份3月的个人草案现已到期归档。10月的报告把其中的问题带回运营现场。

类似边界不止于加号。RFC 7951把一部分整数表示为JSON数字，却把int64、uint64和decimal64表示为字符串；CBOR还能用紧凑标记。代理若只看表面字符、不认模型，格式兼容层就替用户做了类型选择。这条选择常常比界面按钮更有实权。

幻灯片也直说CORECONF部分工作尚未完成。已经部署的接口可以从小处验起：让有类型的值沿每条宣称支持的通道走一遍，读回设备实际应用的结果。测试记录里，该有字节，也该有它们的“身份证”。

原始资料