Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Configuring RFC-Compliant NETCONF Sessions

 

When using NETCONF to manage devices running Junos OS, you can require that the NETCONF server enforce certain behaviors that are compliant with RFC 4741, NETCONF Configuration Protocol during the NETCONF session by configuring the rfc-compliant statement at the [edit system services netconf] hierarchy level. Configuring the rfc-compliant statement affects the following aspects of the NETCONF session:

  • Namespaces emitted in NETCONF server replies

  • <get> and <get-config> elements in RPC replies in cases where there is no configuration data to return

  • NETCONF server replies that would return both an <ok/> element and an <rpc-error> element with a severity level of warning

The differences are described in detail in the following sections:

Namespaces

In a NETCONF session with a device running Junos OS, the NETCONF server, by default, sets the default namespace to the NETCONF namespace in the opening tag of the server’s reply, and NETCONF tag names are not qualified. For example:

When the rfc-compliant statement is configured on the device, the NETCONF server does not define a default namespace in its replies. Instead, the server includes a namespace declaration for the NETCONF namespace, which is bound to the nc prefix, and qualifies all NETCONF tags in its replies with the prefix. If you set the default namespace to the NETCONF namespace in an RPC request, the server discards the default namespace and emits its reply using only the declared namespace that is bound to the nc prefix.

The following sample output shows the NETCONF server’s <hello> message and capabilities exchange when the rfc-compliant statement is configured. The <hello> tag contains the xmlns:nc declaration, and all NETCONF tags include the nc prefix.

The following output shows a sample RPC reply when the rfc-compliant statement is configured:

Starting with Junos OS Release 17.2R1, when you configure the rfc-compliant statement and request configuration data in a NETCONF session, the server sets the default namespace for the <configuration> element to the same namespace as in the corresponding YANG model.

Changes to <get> and <get-config> Operations

The rfc-compliant statement affects the <get> and <get-config> server replies in cases where there is no configuration data to return. This can occur, for example, when you apply a filter to return a subset of the configuration, and that portion of the configuration is empty.

If you execute the <get> or <get-config> operation, and there is no configuration data in the requested hierarchy, then if the rfc-compliant statement is not configured, the RPC reply contains an empty <configuration> element inside the <data> element.

If you execute the <get> or <get-config> operation, and there is no configuration data in the requested hierarchy, then if the rfc-compliant statement is configured, the RPC reply returns an empty <data> element and omits the <configuration> element.

<rpc-error> Elements with a Severity Level of Warning in RPC Replies

Starting in Junos OS Release 17.4R3, 18.2R2, 18.3R2, and 18.4R1, when you configure the rfc-compliant statement, the NETCONF server cannot return an RPC reply that includes both an <rpc-error> element and an <ok/> element. If the operation is successful, but the server reply would include one or more <rpc-error> elements with a severity level of warning in addition to the <ok/> element, then the warnings are omitted. In earlier releases, or when the rfc-compliant statement is not configured, the NETCONF server might issue an RPC reply that includes both an <rpc-error> element with a severity level of warning and an <ok/> element.

For example, in earlier releases, or if the rfc-compliant statement is not configured, a commit operation might be successful but return a warning as in the following NETCONF server reply:

When the rfc-compliant statement is configured in the affected releases, the warning is omitted.

Related Documentation

Release History Table
Release
Description
Starting in Junos OS Release 17.4R3, 18.2R2, 18.3R2, and 18.4R1, when you configure the rfc-compliant statement, the NETCONF server cannot return an RPC reply that includes both an <rpc-error> element and an <ok/> element.