NETCONF Message Formats

This section describes NETCONF message structures.

Figure 1 Structure of a NETCONF YANG message

A NETCONF message consists of the following three parts:

Message: The message layer provides a simple and independent transmission frame mechanism for RPC messages. The client encapsulates an RPC request into an <rpc> element. The server encapsulates the request processing result in the <rpc-reply> element and responds to the client.
Operations: The operations layer defines a set of basic NETCONF operations, and the operations are invoked by RPC methods that are based on XML encoding parameters.
Content: The content (managed object) layer defines a configuration data model. Currently, mainstream configuration data models include the schema and YANG models.

The message's fields are as follows:

message-id: indicates the information code. The value is specified by the client that initiates the RPC request. After receiving the RPC request message, the server saves the message-id attribute, which is used when the <rpc-reply> message is generated.
"urn:ietf:params:xml:ns:netconf:base:1.0": indicates the namespace of the NETCONF XML. "base" indicates that basic operation types are supported.
- base1.0: indicates that the <running/> configuration database is supported. Basic operations, such as <get-config>, <get>, <edit-config>, <copy-config>, <delete-config>, <lock>, <unlock>, <close-session>, and <kill-session>, are defined. You can set the <error-option> parameter to stop-on-error, continue-on-error, or rollback-on-error.
- base1.1: base1.1 is an upgrade of base:1.0, with the following items being changed.
  - The remove operation is added to the operation attribute of <edit-config>.
  - The well-known error-tagmalformed-message is added, and the well-known error-tagpartial-operation is obsolete.
  - The namespace wildcarding mechanism is added for subtree filtering.
  - The chunked framing mechanism is added to resolve the security issues in the end-of-message (EOM) mechanism.
  If you want to perform an operation in base1.1, the client must support base1.1 so that this capability can be advertised during capability set exchanges.
<edit-config>: indicates the operation type.
<target>: indicates the target file to be operated on.
<default-operation>: indicates the default operation type.
<error-option>: indicates the mode for processing subsequent operations if an error occurs when <edit-config> is set. The options are as follows:
- stop-on-error: stops the operation if an error occurs.
- continue-on-error: records the error information and continues the execution if an error occurs. The NETCONF server returns to the client an <rpc-reply> message indicating an operation failure if an error occurs.
- rollback-on-error: stops the operation if an error occurs and rolls back the configuration to the state before the <edit-config> operation is performed. This operation is supported only when the device supports the <rollback-on-error> capability.
<config>: indicates a group of hierarchical configuration items defined in the data model. The configuration items must be placed in the specified namespace and meet the constraints of that data model, as defined by its capability set.
]]>]]>: indicates the end character of an XML message.

The XML messages sent by a client to a server must be concluded with the end character ]]>]]>. Otherwise, the server fails to identify the XML messages and does not respond to them. By default, the end character is automatically added to XML messages sent by a device. In the following example, the end character is not added, which facilitates XML format identification. In practice, the end character must be added.

If the capability set in the <hello> elements contains base1.1, the RPC messages in YANG model support the chunk format. Messages in chunk format can be fragmented. The end character is \n##\n.

Response messages:

For a successful response, an <rpc-reply> message carrying the <ok> element is returned.

<rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <ok />
</rpc-reply>

For a failed response, an <rpc-reply> message carrying the <rpc-error> element is returned.
```
<?xml version="1.0" encoding="utf-8"?>
 <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="3">
  <rpc-error>
   <error-type>application</error-type>
   <error-tag>bad-element</error-tag>
   <error-severity>error</error-severity>
   <error-app-tag>43</error-app-tag>
   <error-path xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0"
   xmlns:acl="http://www.huawei.com/netconf/vrp/huawei-acl">/nc:rpc/nc:edit-config/nc:config/acl:acl/acl:aclGroups/acl:aclGroup[acl:aclNumOrName="2999"]/acl:aclRuleBas4s/acl:aclRuleBas4[acl:aclRuleName="rule_-2"]/acl:vrfAny</error-path>
   <error-message xml:lang="en">vrfAny has invalid value a.</error-message>
   <error-info>
    <bad-element>vrfAny</bad-element>
  </error-info>
 </rpc-error>
</rpc-reply>
```
The message's fields are as follows:
- <error-type>: defines the protocol layer of an error. The layer can be the transport, RPC, protocol, or application layer.
- <error-tag>: indicates the content of an error.
- <error-severity>: indicates the severity of an error. The value can be error or warning.
- <error-app-tag>: indicates a specific error type. This element does not appear if the correct <error-tag> is not associated with the error type.
- <error-path>: indicates the location where an error occurs and the file name.
- <error-message>: indicates the description of an error.
- <error-info>: contains the error content specific to a protocol or data model. This element does not appear if the correct <error info> is not provided.
- <bad-element>: indicates the list of error parameters.