配置符合 RFC 的 NETCONF 会话

命名 空间

默认情况下，NETCONF 服务器在服务器的回复的开始标记中将默认命名空间设置为 NETCONF 命名空间，而 NETCONF 标记名称没有限制。例如：

配置 rfc-compliant 语句时，NETCONF 服务器不会在其回复中定义默认命名空间。相反，服务器会为 NETCONF 命名空间提供一个命名空间声明，该声明绑定到 nc 前缀，并在其回复中使用前缀限制所有 NETCONF 标记。如果在 RPC 请求中将默认命名空间设置为 NETCONF 命名空间，服务器将丢弃默认命名空间，并仅使用绑定到 nc 前缀的已声明命名空间发出其回复。

以下示例输出显示配置语句时 rfc-compliant NETCONF 服务器<hello>的消息和功能交换。标记<hello>包含xmlns:nc声明，所有 NETCONF 标记均包含nc前缀。

以下输出显示配置语句时 rfc-compliant 的示例 RPC 回复：

从 Junos OS 17.2R1 版开始，当您在 NETCONF 会话中配置 rfc-compliant 语句并请求配置数据时，服务器会将该元素的默认命名空间 <configuration> 设置为与相应 YANG 模型中的同一命名空间。

<get> 和 <get-config> 操作的更改

如果没有要返回的配置数据，语句rfc-compliant会影响<get><get-config>和服务器回复。例如，当您应用过滤器以返回配置的子集且配置的那部分为空时，可能会发生这种情况。

如果执行<get>或<get-config>操作，并且请求的层次结构中没有配置数据，则rfc-compliant如果未配置语句，则 RPC 回复将在<data>元素中包含一个空<configuration>元素。

如果执行 <get> 或 <get-config> 操作，并且请求的层次结构中没有配置数据，则 rfc-compliant 如果配置了语句，RPC 回复将返回空 <data> 元素，并省略该 <configuration> 元素。

<rpc 错误> RPC 回复中具有严重级别警告的元素

从 Junos OS 17.4R3、18.2R2、18.3R2 和 18.4R1 版开始，配置语句时rfc-compliant，NETCONF 服务器无法返回同时<rpc-error>包含元素和元素的 <ok/> RPC 回复。如果操作成功，但服务器回复除了该元素外<ok/>，还会包含一个或多个<rpc-error>具有严重级别警告的元素，则省略警告。此外，从 Junos OS 21.2R1 版开始，操作期间<commit>省略的任何警告将被重定向到系统日志文件进行跟踪。

在早期版本中，或者未配置语句时 rfc-compliant ，NETCONF 服务器可能会发出 RPC 回复，其中包含 <rpc-error> 具有严重级别警告的元素和 <ok/> 元素。例如，提交操作可能成功，但会返回警告，如以下 NETCONF 服务器回复中所示：

如果配置语句 rfc-compliant ，则省略警告。

NETCONF 服务器对<承诺>和<验证的响应>运维

从 Junos OS 21.2R1 版开始，配置语句时 rfc-compliant ，NETCONF 服务器对 <commit> 操作的响应包括以下更改：

• 如果一个成功的 <commit> 操作返回了包含一个或多个警告的响应，除了在响应中省略之外，警告将被重定向到系统日志文件。

• NETCONF 服务器响应将 <source-daemon> 元素作为元素的子元素 <error-info> 发出，而非元素 <rpc-error> 。

• 如果同时在[edit system services netconf]层次结构级别配置flatten-commit-results语句，NETCONF 服务器只会在其响应中发出<ok/>或<rpc-error>元素，并抑制任何 <commit-results> XML 子树。

从 Junos OS 23.2R1 版开始，当您配置 rfc-compliant 语句时，NETCONF 服务器仅发出一个 <ok/> 或 <rpc-error> 元素来 <validate> 响应操作。在早期版本中，RPC 回复还包括该 <commit-results> 元素。