Parsing the NETCONF Server Response
The NETCONF server encloses its response to each client request in a separate pair of opening <rpc-reply> and closing </rpc-reply> tags. Each response constitutes a well-formed XML document. The opening <rpc-reply> tag includes the xmlns and xmlns:junos attributes (the opening tag appears here on multiple lines for legibility only):
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" \
xmlns:junos="http://xml.juniper.net/junos/release/junos" \
[echoed attributes]>
<!-- tag elements representing a response -->
</rpc-reply>
]]>]]>
The xmlns attribute defines the namespace for enclosed tag elements that do not have the junos: prefix on their names and that are not enclosed in a child container tag that has the xmlns attribute with a different value.
The xmlns:junos attribute defines the namespace for enclosed Junos XML tag elements that have the junos: prefix on their names. The variable release is replaced by a code such as 13.2R1 for the initial version of Junos OS Release 13.2.
Client applications must include code for parsing the stream of response tag elements coming from the NETCONF server, either processing them as they arrive or storing them until the response is complete. The NETCONF server returns three classes of responses:
Operational Responses
Operational responses are responses to requests for information about the status of a switching, routing, or security platform. They correspond to the output from CLI operational commands as described in the Junos OS command references.
The Junos XML API defines response tag elements for all defined operational request tag elements. For example, the NETCONF server returns the information requested by the <get-interface-information> tag element in a response tag element called <interface-information> and returns the information requested by the <get-chassis-inventory> tag element in a response tag element called <chassis-inventory>. Operational responses also can be returned in formatted ASCII, which is enclosed in an <output> tag element. For more information about formatting operational responses see Specifying the Output Format for Operational Information Requests in a NETCONF Session.
The following sample response includes information about the interface ge-2/3/0. The namespace indicated by the xmlns attribute in the opening <interface-information> tag is for interface information in the initial version of Junos OS Release 13.2. The opening tags appear on two lines here for legibility only:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"\
xmlns:junos="http://xml.juniper.net/junos/13.2R1/junos">
<interface-information \
xmlns="http://xml.juniper.net/junos/13.2R1/junos-interface">
<physical-interface>
<name>ge-2/3/0</name>
<!-- other data tag elements for the ge-2/3/0 interface - ->
</physical-interface>
</interface-information>
</rpc-reply>
]]>]]>
For more information about the xmlns attribute and the contents of operational response tag elements, see Requesting Operational Information Using NETCONF. For a summary of operational response tag elements, see the Junos XML API Operational Reference.
Configuration Information Responses
Configuration information responses are responses to requests for information about the device’s current configuration. The Junos XML API defines a tag element for every container and leaf statement in the configuration hierarchy.
The following sample response includes the information at the [edit system login] hierarchy level in the configuration hierarchy. For brevity, the sample shows only one user defined at this level. The opening <rpc-reply> tag appears on two lines for legibility only. For information about the attributes in the opening <configuration> tag, see Requesting Committed or Candidate Configuration Information Using NETCONF.
Configuration Change Responses
Configuration change responses are responses to requests that change the state or contents of the device configuration. The NETCONF server indicates successful execution of a request by returning the <ok/> tag within the <rpc-reply> tag element:
If the operation fails, the <rpc-reply> tag element instead encloses an <rpc-error> tag element that describes the cause of the failure. For information about handling errors, see Handling an Error or Warning in a NETCONF Session.
