Configure RFC-Compliant NETCONF Sessions
When you use NETCONF to manage Junos devices, you can require that the NETCONF server enforce
certain behaviors that are compliant with RFC 4741, NETCONF Configuration Protocol
during the NETCONF session. To enforce RFC compliance, configure 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
-
Elements returned in RPC replies for
<get>and<get-config>operations 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 - NETCONF server replies for
<commit>and<validate>operations.
The differences are described in detail in the following sections.
Namespaces
By default, the NETCONF server, 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:
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<capabilities>
<capability>urn:ietf:params:netconf:base:1.0</capability>
...
</capabilities>
<session-id>27700</session-id>
<hello>
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/15.1R1/junos">
When you configure the rfc-compliant statement, 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.
<nc:hello xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
<nc:capabilities>
<nc:capability>urn:ietf:params:netconf:base:1.0</nc:capability>
...
</nc:capabilities>
<nc:session-id>27703</nc:session-id>
</nc:hello>The following output shows a sample RPC reply when the rfc-compliant
statement is configured:
<nc:rpc-reply
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:junos="http://xml.juniper.net/junos/15.1R1/junos">
<nc:data>
<configuration xmlns="http://xml.juniper.net/xnm/1.1/xnm"
junos:changed-seconds="1417554471"
junos:changed-localtime="2014-12-02 13:07:51 PST">
<!--configuration data-->
</configuration>
<database-status-information>
<database-status>
<user>root</user>
<terminal></terminal>
<pid>47868</pid>
<start-time junos:seconds="1417560303">2014-12-02 14:45:03 PST</start-time>
<edit-path></edit-path>
</database-status>
</database-status-information>
</nc:data>
</nc:rpc-reply>
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.
<rpc>
<get-config>
<source>
<running/>
</source>
</get-config>
</rpc>
]]>]]>
<nc:rpc-reply
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
xmlns:junos="http://xml.juniper.net/junos/17.2R1/junos">
<nc:data>
<configuration
xmlns="http://yang.juniper.net/yang/1.1/jc/configuration/junos/17.2R1.13"
junos:commit-seconds="1493761452"
junos:commit-localtime="2017-05-02 14:44:12 PDT"
junos:commit-user="user">
...
</configuration>
</nc:data>
</nc:rpc-reply>
]]>]]>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.
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/15.1D0/junos"> <data> <configuration> </configuration> </data> </rpc-reply>
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.
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/15.1R1/junos"> <nc:data> </nc:data> </nc:rpc-reply>
<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 addition, starting in Junos OS Release 21.2R1, any warnings that are omitted
during a <commit> operation are redirected to the system log file for
tracking.
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, a commit operation might be successful
but return a warning as in the following NETCONF server reply:
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/17.4R1/junos">
<nc:rpc-error>
<nc:error-severity>warning</nc:error-severity>
<nc:error-message>
uid changed for jadmin (2001->2014)
</nc:error-message>
</nc:rpc-error>
<nc:ok/>
</nc:rpc-reply>
]]>]]>If you configure the rfc-compliant statement, then the warning is
omitted.
<nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/18.4R1/junos"> <nc:ok/> </nc:rpc-reply> ]]>]]>
NETCONF Server Response to <commit> and <validate> Operations
Starting in Junos OS Release 21.2R1, when you configure the rfc-compliant
statement, the NETCONF server's response to <commit> operations
includes the following changes:
-
If a successful
<commit>operation returns a response with one or more warnings, the warnings are redirected to the system log file, in addition to being omitted from the response. -
The NETCONF server response emits the
<source-daemon>element as a child of the<error-info>element instead of the<rpc-error>element. -
If you also configure the
flatten-commit-resultsstatement at the[edit system services netconf]hierarchy level, the NETCONF server only emits an<ok/>or<rpc-error>element in its response and suppresses any<commit-results>XML subtree.
Starting in Junos OS Release 23.2R1 and Junos OS Evolved Release 23.4R1, when you configure
the rfc-compliant statement, the NETCONF server emits only an
<ok/> or <rpc-error> element in response to
<validate> operations. In earlier releases, the RPC reply also
includes the <commit-results> element.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
rfc-compliant statement, the NETCONF server emits
only an <ok/> or <rpc-error> element in
response to <validate> operations. In earlier releases, the RPC
reply also includes the <commit-results> element.rfc-compliant statement, the NETCONF server's response to
<commit> operations is modified.rfc-compliant statement, the NETCONF server cannot return
an RPC reply that includes both an <rpc-error> element and an
<ok/> element.