Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Announcement: Try the Ask AI chatbot for answers to your technical questions about Juniper products and solutions.

close
header-navigation
keyboard_arrow_up
close
keyboard_arrow_left
list Table of Contents
file_download PDF
{ "lLangCode": "en", "lName": "English", "lCountryCode": "us", "transcode": "en_US" }
English
keyboard_arrow_right

Generate Well-Formed XML Documents

date_range 27-Nov-24

Each set of NETCONF and Junos XML tag elements emitted by the NETCONF server and a client application within a <hello>, <rpc>, or <rpc-reply> tag element must constitute a well-formed XML document. That is, it must obey the structural rules defined in the document type definition (DTD) for the kind of information being sent. The client application must emit tag elements in the required order and only in the allowed contexts.

NETCONF sessions use a framing mechanism to separate the messages that the NETCONF server and client send within the session. The NETCONF server and client must emit messages using the framing mechanism appropriate for that session. Junos devices support the following framing mechanisms:

  • End-of-document character sequence (]]>]]>)—Message separator defined in RFC 4742 Using the NETCONF Configuration Protocol over Secure SHell (SSH)

  • Chunked framing—Framing mechanism defined in RFC 6242, Using the NETCONF Protocol over Secure Shell (SSH), which encodes all NETCONF messages with chunked framing.

You can configure supported Junos devices to comply with RFC 6242 by configuring the rfc-compliant and version-1.1 statements at the [edit system services netconf] hierarchy level. When you enable RFC 6242 compliance and both peers advertise the :base:1.1 capability, the NETCONF session uses the chunked framing mechanism for the remainder of the session. For more information, see Configure RFC-Compliant NETCONF Sessions.

If the NETCONF session does not use the chunked framing mechanism, the NETCONF server and client applications comply with RFC 4742. In particular, the server and applications send the end-of-document character sequence ]]>]]> after each XML document. In practice, the client application sends the sequence after the closing </hello> tag and each closing </rpc> tag, and the NETCONF server sends it after the closing </hello> tag and each closing </rpc-reply> tag.

The following example demonstrates the general structure of the XML document and the ]]>]]> character sequence in a NETCONF session:

content_copy zoom_out_map
<!-- generated by the client application -->
<hello | rpc>
    <!-- contents of top-level tag element  -->
</hello | /rpc>
]]>]]>
   
<!-- generated by the NETCONF server -->
<hello | rpc-reply attributes>
    <!-- contents of top-level tag element  -->
</hello | /rpc-reply>
]]>]]>

When the NETCONF session uses chunked framing, the server and client encode all NETCONF messages as chunked following the Augmented Backus-Naur Form (ABNF) rule Chunked-Message. The following example uses chunked framing:

content_copy zoom_out_map
<!-- generated by the client application -->
\n#140\n
<?xml version="1.0" encoding="UTF-8"?>\n
<rpc message-id="106"\n
     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">\n
   <close-session/>\n
</rpc>
\n##\n


<!-- generated by the NETCONF server -->
\n#139\n
<?xml version="1.0" encoding="UTF-8"?>\n
<rpc-reply id="106"\n
           xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">\n
  <ok/>\n
</rpc-reply>
\n##\n
footer-navigation