0

考虑以下 yang 模块

module mod {
    yang-version 1;
    namespace "http://example.com/mod";
    prefix m;
    revision "2016-09-09" {
       description "Initial revision.";
    }
    container foo {
        description 'container foo';
        leaf l {
            type string;
        }
    }
}

到达叶子 l 时哪个路径表达式是正确的？

/mod:foo/l
/m:foo/l
/foo/l

如果我的应用程序中有同一个模块的两个版本处于活动状态，客户如何表达他对哪个版本节点感兴趣？

并且，是否有路径表达式可用于引用叶子 l 的“描述”？

4

1 回答 1

1

到达叶子 l 时哪个路径表达式是正确的？

在 RESTCONF GET 的上下文中，使用了draft-ietf-netconf-restconf-16 第 3.5.3 节，在请求 URI 中编码数据资源标识符中描述的方案。

RESTCONF 数据资源标识符从左到右编码，从顶层数据节点开始，根据 3.5.3.1 节中的“api-path”规则。目标资源节点的每个祖先的节点名称按顺序编码，以目标资源的节点名称结尾。如果路径中的节点在其父节点之外的另一个模块中定义，或者其父节点是数据存储，则模块名称后跟冒号字符（“：”）必须添加到资源标识符中的节点名称之前。有关详细信息，请参阅第 3.5.3.1 节。

因此正确的 URI 应该是这样的：

/restconf/data/mod:foo/l

如果我的应用程序中有同一个模块的两个版本处于活动状态，客户如何表达他对哪个版本节点感兴趣？

你不能表达这样的要求。这就是为什么只允许服务器实现 YANG 模块的单个修订的原因之一。在 YANG 1.1 中，这是明确禁止的，而在 YANG 1.0 中，这只是暗示的。请注意，各个已实现的 YANG 模块可能会引用（导入）同一模块的多个修订版，但其中只有一个可能被宣传为已实现（可能是最新的）。由于模块更新规则非常严格，定义不会在模块的较新版本中丢失，因此客户端是安全的。

是否有路径表达式可用于引用叶子 l 的“描述”？我的“描述”用例是这样的。客户端向服务器提交一个 yang 模块。客户希望确保服务器正确地看到结构。客户说，“给我看那片叶子的描述”，或者，“叶子的默认值是什么”等。

您似乎误解了 YANG 模型的角色。客户端不管理服务器的模型，它可能只管理该模型中描述的数据！这样的事情在服务器及其维护者的域中。

查询 YANG 模型（我知道）而不是由它建模的数据的唯一标准方法是从服务器（get-schema）获取 YANG/YIN 文件，然后自己解析它。

作为旁注。实现您的模块并从服务器接收有效响应的客户端固有地知道哪个描述映射到哪个 XML 元素/JSON 对象，因为它已经在验证期间完成了实例文档和模型（模式）之间的“映射”阶段。

于 2016-09-20T08:17:54.610 回答