<get-config>

A <get-config> operation is supported on the <candidate> datastore.

The <get-config> requests on the <candidate> datastore return only XML-formatted content. If no filter is specified for the <candidate> datastore, SR OS returns only the Nokia SR OS configurations.

For the Nokia SR OS YANG modules, <get-config> requests that specify a nonexistent list node or presence container result in an <rpc-error> response.

For the ‟report-all” value with the <with-defaults> tag (RFC 6243) in an XML- content layer, <get-config> returns the equivalent of the CLI command info detail (the returned data includes attributes that are set to their default values).

Subtree filtering is supported for <get-config> (and <get> requests). The following is the subtree filtering behavior.

Containment nodes are supported (section 6.2.3 of RFC 6241). Nodes that contain children nodes (containers) can be used for subtree filtering. See Containment node for more information.
Attribute match expressions (section 6.2.2 of RFC 6241) are not supported.
Selection nodes are supported (section 6.2.4 of RFC 6241). Empty leaf nodes and list name nodes can be used as selection nodes. A selection node that is a list and does not have a key specified is supported. See Non-key leaf specified as selection node for more information.
Content match nodes are supported (section 6.2.5 of RFC 6241). Content match nodes that are leafs but not keys are also supported. See Non-key leaf specified as a content match node for more information.

The <get-config> operation returns data nodes set by a client to their default Nokia SR OS model values (the ‟explicit” mode as described in RFC 6243).

To retrieve BOF configurations, the ‟bof” <configuration-region> must be specified within the <get-config> <source>. For example:

<?xml version="1.0" encoding="UTF-8"?> 
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get-config>
  <source>
     <configuration-region>bof</configuration-region>
     <running/>
  </source>
    <filter>
        <bof xmlns="urn:nokia.com:sros:ns:yang:sr:bof-conf">
        </bof>
    </filter>
</get-config>
</rpc>
]]>]]>

To retrieve LI configurations, the ‟li” <configuration-region> must be specified within the <get-config> <source>. For example:

<get-config>
  <source>
    <configuration-region>li</configuration-region>
    <candidate/>
  </source>
    <filter>
       …
    </filter>
</get-config>

Alternatively, the <source> can be specified in the format of ‟configuration-region”-”datastore”. For example:

<get-config>
  <source>
    <li-candidate/>
  </source>
    <filter>
       …
    </filter>
</get-config>

When both the <configuration-region> and the ‟configuration-region”-‟datastore” format are used, SR OS applies the last tag used in the XML request. For example:

<get-config>
  <source>
    <configuration-region>configure</configuration-region>
      <li-candidate/>
  </source>
    <filter>
      …
    </filter>
</get-config>

In the preceding example, the <get-config> is used to retrieve the ‟li” configuration data from the ‟li” candidate datastore.

When a mismatched namespace or <configuration-region> combination is specified, SR OS returns an empty <data>.

See Table: Protocol operations and level of support in Nokia SR OS NETCONF servers for more details.

If present, configuration annotations are encoded with the nokia-attr:comment attribute. In the following example, configure system name is annotated with the comment "This is a comment on the system name." in the RPC reply:

<?xml version="1.0" encoding="UTF-8"?>
<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
    <data>
        <configure xmlns="urn:nokia.com:sros:ns:yang:sr:conf" xmlns:nokia-attr="urn:nokia.com:sros:ns:yang:sr:attributes">
            <system>
                <name nokia-attr:comment="This is a comment on the system name."> node2</name>
            </system>
        </configure>
    </data>
</rpc-reply>

The optional proprietary <format> argument is supported. See Output format selection for more information.

The following sections contain examples of <get-config> request and response messages.