Using Ctrl-c in a NETCONF session will immediately terminate the session.
The SR OS NETCONF implementation supports XML namespaces (xmlns).
If an invalid namespace is specified within the client hello message, no error will be returned because the NETCONF server is still waiting for the client to send a valid <hello/>. For further NETCONF requests (without sending a correct hello message), even though correct, SR OS returns an error indicating that ‟Common base capability not found.”
In the <rpc> element, the allowed XML namespaces are:
standard NETCONF ‟urn:ietf:params:xml:ns:netconf:base:1.0” namespace
Nokia SR OS namespaces; for example, ‟urn:nokia.com:sros:ns:yang:sr:conf” namespace or ‟urn:nokia.com:sros:ns:yang:sr:state” namespace
In the <rpc> element, prefixes are accepted and have to be specified with a valid URI. If an incorrect URI is declared with a prefix, SR OS detects the invalid URI and sends an <rpc-error> response.
If any other XML namespace is declared (or assigned to a prefix) in the <rpc> element, SR OS returns an error.
Any prefix declarations in the rest of the request are ignored and unused. The SR OS NETCONF server puts the correct NETCONF namespace declaration (‟urn:ietf:params:xml:ns:netconf:base:1.0”) in all replies.
An <edit-config> request must specify which data model (for example, Nokia SR OS YANG modules) is being used in the top-level <configure> element.
SR OS accepts a single namespace at the top-level <configure> element. For example:
<configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf">
<system>
....
The NETCONF client can declare the namespaces with prefixes at the <rpc> element and use the corresponding prefixes later in the request message <configure/> block.
SR OS returns an error if the request contains one or more incorrect namespaces.
The chunked framing mechanism is supported in addition to the EOM mechanism. As per RFC 6242, Section 4.1 - Framing Protocol, ‟[...] If the :base:1.1 capability is advertised by both peers, the chunked framing mechanism (see Section 4.2) is used for the remainder of the NETCONF session. Otherwise, the end-of-message-based mechanism is used.” See Chunked frame mechanism for more information.
Handling of default data (for example, info vs info detail) uses the mechanisms described in RFC 6243. The SR OS NETCONF server supports the ‟explicit” method as the default for the Nokia SR OS YANG modules. It also supports the ‟report-all” method.
The advertised capability changes depending on which YANG modules are enabled or disabled in SR OS. For example, when Nokia modules are enabled and all other modules are disabled, the following capability is advertised:
<capability>urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit&also-supported=report-all</capability>
A debug system netconf info command can be used to dump NETCONF debug message streams. Note that in case of failure, the current logging levels do not mark the messages as errors or warnings.