Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6241

Network Configuration Protocol (NETCONF)

Pages: 113
Proposed Standard
Errata
Obsoletes:  4741
Updated by:  7803
Part 4 of 5 – Pages 61 to 85
First   Prev   Next

Top   ToC   RFC6241 - Page 61   prevText

8.5. Rollback-on-Error Capability

8.5.1. Description

This capability indicates that the server will support the "rollback-on-error" value in the <error-option> parameter to the <edit-config> operation. For shared configurations, this feature can cause other configuration changes (for example, via other NETCONF sessions) to be inadvertently altered or removed, unless the configuration locking feature is used (in other words, the lock is obtained before the <edit-config> operation is started). Therefore, it is strongly suggested that in order to use this feature with shared configuration datastores, configuration locking also be used.
Top   ToC   RFC6241 - Page 62

8.5.2. Dependencies

None.

8.5.3. Capability Identifier

The :rollback-on-error capability is identified by the following capability string: urn:ietf:params:netconf:capability:rollback-on-error:1.0

8.5.4. New Operations

None.

8.5.5. Modifications to Existing Operations

8.5.5.1. <edit-config>
The :rollback-on-error capability allows the "rollback-on-error" value to the <error-option> parameter on the <edit-config> operation. <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <error-option>rollback-on-error</error-option> <config> <top xmlns="http://example.com/schema/1.2/config"> <interface> <name>Ethernet0/0</name> <mtu>100000</mtu> </interface> </top> </config> </edit-config> </rpc> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply>
Top   ToC   RFC6241 - Page 63

8.6. Validate Capability

8.6.1. Description

Validation consists of checking a complete configuration for syntactical and semantic errors before applying the configuration to the device. If this capability is advertised, the device supports the <validate> protocol operation and checks at least for syntax errors. In addition, this capability supports the <test-option> parameter to the <edit-config> operation and, when it is provided, checks at least for syntax errors. Version 1.0 of this capability was defined in [RFC4741]. Version 1.1 is defined in this document, and extends version 1.0 by adding a new value, "test-only", to the <test-option> parameter of the <edit-config> operation. For backwards compatibility with old clients, servers conforming to this specification MAY advertise version 1.0 in addition to version 1.1.

8.6.2. Dependencies

None.

8.6.3. Capability Identifier

The :validate:1.1 capability is identified by the following capability string: urn:ietf:params:netconf:capability:validate:1.1

8.6.4. New Operations

8.6.4.1. <validate>
Description: This protocol operation validates the contents of the specified configuration. Parameters: source: Name of the configuration datastore to validate, such as <candidate>, or the <config> element containing the complete configuration to validate.
Top   ToC   RFC6241 - Page 64
   Positive Response:

         If the device was able to satisfy the request, an <rpc-reply>
         is sent that contains an <ok> element.

   Negative Response:

         An <rpc-error> element is included in the <rpc-reply> if the
         request cannot be completed for any reason.

         A <validate> operation can fail for a number of reasons, such
         as syntax errors, missing parameters, references to undefined
         configuration data, or any other violations of rules
         established by the underlying data model.

   Example:

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

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

8.6.5. Modifications to Existing Operations

8.6.5.1. <edit-config>
The :validate:1.1 capability modifies the <edit-config> operation to accept the <test-option> parameter.

8.7. Distinct Startup Capability

8.7.1. Description

The device supports separate running and startup configuration datastores. The startup configuration is loaded by the device when it boots. Operations that affect the running configuration will not be automatically copied to the startup configuration. An explicit <copy-config> operation from the <running> to the <startup> is used to update the startup configuration to the current contents of the
Top   ToC   RFC6241 - Page 65
   running configuration.  NETCONF protocol operations refer to the
   startup datastore using the <startup> element.

8.7.2. Dependencies

None.

8.7.3. Capability Identifier

The :startup capability is identified by the following capability string: urn:ietf:params:netconf:capability:startup:1.0

8.7.4. New Operations

None.

8.7.5. Modifications to Existing Operations

8.7.5.1. General
The :startup capability adds the <startup/> configuration datastore to arguments of several NETCONF operations. The server MUST support the following additional values: +--------------------+--------------------------+-------------------+ | Operation | Parameters | Notes | +--------------------+--------------------------+-------------------+ | <get-config> | <source> | | | | | | | <copy-config> | <source> <target> | | | | | | | <lock> | <target> | | | | | | | <unlock> | <target> | | | | | | | <validate> | <source> | If :validate:1.1 | | | | is advertised | | | | | | <delete-config> | <target> | Resets the device | | | | to its factory | | | | defaults | +--------------------+--------------------------+-------------------+ To save the startup configuration, use the <copy-config> operation to copy the <running> configuration datastore to the <startup> configuration datastore.
Top   ToC   RFC6241 - Page 66
     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <copy-config>
         <target>
           <startup/>
         </target>
         <source>
           <running/>
         </source>
       </copy-config>
     </rpc>

8.8. URL Capability

8.8.1. Description

The NETCONF peer has the ability to accept the <url> element in <source> and <target> parameters. The capability is further identified by URL arguments indicating the URL schemes supported.

8.8.2. Dependencies

None.

8.8.3. Capability Identifier

The :url capability is identified by the following capability string: urn:ietf:params:netconf:capability:url:1.0?scheme={name,...} The :url capability URI MUST contain a "scheme" argument assigned a comma-separated list of scheme names indicating which schemes the NETCONF peer supports. For example: urn:ietf:params:netconf:capability:url:1.0?scheme=http,ftp,file

8.8.4. New Operations

None.

8.8.5. Modifications to Existing Operations

8.8.5.1. <edit-config>
The :url capability modifies the <edit-config> operation to accept the <url> element as an alternative to the <config> parameter.
Top   ToC   RFC6241 - Page 67
   The file that the url refers to contains the configuration data
   hierarchy to be modified, encoded in XML under the element <config>
   in the "urn:ietf:params:xml:ns:netconf:base:1.0" namespace.

8.8.5.2. <copy-config>
The :url capability modifies the <copy-config> operation to accept the <url> element as the value of the <source> and the <target> parameters. The file that the url refers to contains the complete datastore, encoded in XML under the element <config> in the "urn:ietf:params:xml:ns:netconf:base:1.0" namespace.
8.8.5.3. <delete-config>
The :url capability modifies the <delete-config> operation to accept the <url> element as the value of the <target> parameters.
8.8.5.4. <validate>
The :url capability modifies the <validate> operation to accept the <url> element as the value of the <source> parameter.

8.9. XPath Capability

8.9.1. Description

The XPath capability indicates that the NETCONF peer supports the use of XPath expressions in the <filter> element. XPath is described in [W3C.REC-xpath-19991116]. The data model used in the XPath expression is the same as that used in XPath 1.0 [W3C.REC-xpath-19991116], with the same extension for root node children as used by XSLT 1.0 ([W3C.REC-xslt-19991116], Section 3.1). Specifically, it means that the root node MAY have any number of element nodes as its children. The XPath expression is evaluated in the following context: o The set of namespace declarations are those in scope on the <filter> element. o The set of variable bindings is defined by the data model. If no such variable bindings are defined, the set is empty. o The function library is the core function library, plus any functions defined by the data model.
Top   ToC   RFC6241 - Page 68
   o  The context node is the root node.

   The XPath expression MUST return a node set.  If it does not return a
   node set, the operation fails with an "invalid-value" error.

   The response message contains the subtrees selected by the filter
   expression.  For each such subtree, the path from the data model root
   node down to the subtree, including any elements or attributes
   necessary to uniquely identify the subtree, are included in the
   response message.  Specific data instances are not duplicated in the
   response.

8.9.2. Dependencies

None.

8.9.3. Capability Identifier

The :xpath capability is identified by the following capability string: urn:ietf:params:netconf:capability:xpath:1.0

8.9.4. New Operations

None.

8.9.5. Modifications to Existing Operations

8.9.5.1. <get-config> and <get>
The :xpath capability modifies the <get> and <get-config> operations to accept the value "xpath" in the "type" attribute of the <filter> element. When the "type" attribute is set to "xpath", a "select" attribute MUST be present on the <filter> element. The "select" attribute will be treated as an XPath expression and used to filter the returned data. The <filter> element itself MUST be empty in this case. The XPath result for the select expression MUST be a node-set. Each node in the node-set MUST correspond to a node in the underlying data model. In order to properly identify each node, the following encoding rules are defined: o All ancestor nodes of the result node MUST be encoded first, so the <data> element returned in the reply contains only fully specified subtrees, according to the underlying data model.
Top   ToC   RFC6241 - Page 69
   o  If any sibling or ancestor nodes of the result node are needed to
      identify a particular instance within a conceptual data structure,
      then these nodes MUST also be encoded in the response.

   For example:

     <rpc message-id="101"
          xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <get-config>
         <source>
           <running/>
         </source>
         <!-- get the user named fred -->
         <filter xmlns:t="http://example.com/schema/1.2/config"
                 type="xpath"
                 select="/t:top/t:users/t:user[t:name='fred']"/>
        </get-config>
     </rpc>

     <rpc-reply message-id="101"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <data>
         <top xmlns="http://example.com/schema/1.2/config">
           <users>
             <user>
               <name>fred</name>
               <company-info>
                 <id>2</id>
               </company-info>
             </user>
           </users>
         </top>
       </data>
     </rpc-reply>

9. Security Considerations

This section provides security considerations for the base NETCONF message layer and the base operations of the NETCONF protocol. Security considerations for the NETCONF transports are provided in the transport documents, and security considerations for the content manipulated by NETCONF can be found in the documents defining data models. This document does not specify an authorization scheme, as such a scheme will likely be tied to a meta-data model or a data model. Implementors SHOULD provide a comprehensive authorization scheme with NETCONF.
Top   ToC   RFC6241 - Page 70
   Authorization of individual users via the NETCONF server may or may
   not map 1:1 to other interfaces.  First, the data models might be
   incompatible.  Second, it could be desirable to authorize based on
   mechanisms available in the Secure Transport layer (e.g., SSH, Blocks
   Extensible Exchange Protocol (BEEP), etc.).

   In addition, operations on configurations could have unintended
   consequences if those operations are also not guarded by the global
   lock on the files or objects being operated upon.  For instance, if
   the running configuration is not locked, a partially complete access
   list could be committed from the candidate configuration unbeknownst
   to the owner of the lock of the candidate configuration, leading to
   either an insecure or inaccessible device.

   Configuration information is by its very nature sensitive.  Its
   transmission in the clear and without integrity checking leaves
   devices open to classic eavesdropping and false data injection
   attacks.  Configuration information often contains passwords, user
   names, service descriptions, and topological information, all of
   which are sensitive.  Because of this, this protocol SHOULD be
   implemented carefully with adequate attention to all manner of attack
   one might expect to experience with other management interfaces.

   The protocol, therefore, MUST minimally support options for both
   confidentiality and authentication.  It is anticipated that the
   underlying protocol (SSH, BEEP, etc.) will provide for both
   confidentiality and authentication, as is required.  It is further
   expected that the identity of each end of a NETCONF session will be
   available to the other in order to determine authorization for any
   given request.  One could also easily envision additional
   information, such as transport and encryption methods, being made
   available for purposes of authorization.  NETCONF itself provides no
   means to re-authenticate, much less authenticate.  All such actions
   occur at lower layers.

   Different environments may well allow different rights prior to and
   then after authentication.  Thus, an authorization model is not
   specified in this document.  When an operation is not properly
   authorized, a simple "access denied" is sufficient.  Note that
   authorization information can be exchanged in the form of
   configuration information, which is all the more reason to ensure the
   security of the connection.

   That having been said, it is important to recognize that some
   operations are clearly more sensitive by nature than others.  For
   instance, <copy-config> to the startup or running configurations is
   clearly not a normal provisioning operation, whereas <edit-config>
   is.  Such global operations MUST disallow the changing of information
Top   ToC   RFC6241 - Page 71
   that an individual does not have authorization to perform.  For
   example, if user A is not allowed to configure an IP address on an
   interface but user B has configured an IP address on an interface in
   the <candidate> configuration, user A MUST NOT be allowed to commit
   the <candidate> configuration.

   Similarly, just because someone says "go write a configuration
   through the URL capability at a particular place", this does not mean
   that an element will do it without proper authorization.

   The <lock> operation will demonstrate that NETCONF is intended for
   use by systems that have at least some trust of the administrator.
   As specified in this document, it is possible to lock portions of a
   configuration that a principal might not otherwise have access to.
   After all, the entire configuration is locked.  To mitigate this
   problem, there are two approaches.  It is possible to kill another
   NETCONF session programmatically from within NETCONF if one knows the
   session identifier of the offending session.  The other possible way
   to break a lock is to provide a function within the device's native
   user interface.  These two mechanisms suffer from a race condition
   that could be ameliorated by removing the offending user from an
   Authentication, Authorization, and Accounting (AAA) server.  However,
   such a solution is not useful in all deployment scenarios, such as
   those where SSH public/private key pairs are used.

10. IANA Considerations

10.1. NETCONF XML Namespace

This document registers a URI for the NETCONF XML namespace in the IETF XML registry [RFC3688]. IANA has updated the following URI to reference this document. URI: urn:ietf:params:xml:ns:netconf:base:1.0 Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace.

10.2. NETCONF XML Schema

This document registers a URI for the NETCONF XML schema in the IETF XML registry [RFC3688]. IANA has updated the following URI to reference this document. URI: urn:ietf:params:xml:schema:netconf
Top   ToC   RFC6241 - Page 72
   Registrant Contact: The IESG.

   XML: Appendix B of this document.

10.3. NETCONF YANG Module

This document registers a YANG module in the YANG Module Names registry [RFC6020]. name: ietf-netconf namespace: urn:ietf:params:xml:ns:netconf:base:1.0 prefix: nc reference: RFC 6241

10.4. NETCONF Capability URNs

IANA has created and now maintains a registry "Network Configuration Protocol (NETCONF) Capability URNs" that allocates NETCONF capability identifiers. Additions to the registry require IETF Standards Action. IANA has updated the allocations of the following capabilities to reference this document. Index Capability Identifier ------------------------ :writable-running urn:ietf:params:netconf:capability:writable-running:1.0 :candidate urn:ietf:params:netconf:capability:candidate:1.0 :rollback-on-error urn:ietf:params:netconf:capability:rollback-on-error:1.0 :startup urn:ietf:params:netconf:capability:startup:1.0 :url urn:ietf:params:netconf:capability:url:1.0 :xpath urn:ietf:params:netconf:capability:xpath:1.0
Top   ToC   RFC6241 - Page 73
   IANA has added the following capabilities to the registry:

      Index
         Capability Identifier
      ------------------------

      :base:1.1
         urn:ietf:params:netconf:base:1.1

      :confirmed-commit:1.1
         urn:ietf:params:netconf:capability:confirmed-commit:1.1

      :validate:1.1
         urn:ietf:params:netconf:capability:validate:1.1

11. Contributors

In addition to the editors, this document was written by: Ken Crozier, Cisco Systems Ted Goddard, IceSoft Eliot Lear, Cisco Systems Phil Shafer, Juniper Networks Steve Waldbusser Margaret Wasserman, Painless Security, LLC

12. Acknowledgements

The authors would like to acknowledge the members of the NETCONF working group. In particular, we would like to thank Wes Hardaker for his persistence and patience in assisting us with security considerations. We would also like to thank Randy Presuhn, Sharon Chisholm, Glenn Waters, David Perkins, Weijing Chen, Simon Leinen, Keith Allen, Dave Harrington, Ladislav Lhotka, Tom Petch, and Kent Watsen for all of their valuable advice.
Top   ToC   RFC6241 - Page 74

13. References

13.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote Procedure Call (RPC) for NETCONF", RFC 5717, December 2009. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, October 2010. [RFC6242] Wasserman, M., "Using the NETCONF Configuration Protocol over Secure Shell (SSH)", RFC 6242, June 2011. [W3C.REC-xml-20001006] Sperberg-McQueen, C., Bray, T., Paoli, J., and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium REC-xml-20001006, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>. [W3C.REC-xpath-19991116] DeRose, S. and J. Clark, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xpath-19991116>.
Top   ToC   RFC6241 - Page 75

13.2. Informative References

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [W3C.REC-xslt-19991116] Clark, J., "XSL Transformations (XSLT) Version 1.0", World Wide Web Consortium Recommendation REC-xslt-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xslt-19991116>.
Top   ToC   RFC6241 - Page 76

Appendix A. NETCONF Error List

This section is normative. For each error-tag, the valid error-type and error-severity values are listed, together with any mandatory error-info, if any. error-tag: in-use error-type: protocol, application error-severity: error error-info: none Description: The request requires a resource that already is in use. error-tag: invalid-value error-type: protocol, application error-severity: error error-info: none Description: The request specifies an unacceptable value for one or more parameters. error-tag: too-big error-type: transport, rpc, protocol, application error-severity: error error-info: none Description: The request or response (that would be generated) is too large for the implementation to handle. error-tag: missing-attribute error-type: rpc, protocol, application error-severity: error error-info: <bad-attribute> : name of the missing attribute <bad-element> : name of the element that is supposed to contain the missing attribute Description: An expected attribute is missing. error-tag: bad-attribute error-type: rpc, protocol, application error-severity: error error-info: <bad-attribute> : name of the attribute w/ bad value <bad-element> : name of the element that contains the attribute with the bad value Description: An attribute value is not correct; e.g., wrong type, out of range, pattern mismatch.
Top   ToC   RFC6241 - Page 77
   error-tag:      unknown-attribute
   error-type:     rpc, protocol, application
   error-severity: error
   error-info:     <bad-attribute> : name of the unexpected attribute
                   <bad-element> : name of the element that contains
                     the unexpected attribute
   Description:    An unexpected attribute is present.

   error-tag:      missing-element
   error-type:     protocol, application
   error-severity: error
   error-info:     <bad-element> : name of the missing element
   Description:    An expected element is missing.

   error-tag:      bad-element
   error-type:     protocol, application
   error-severity: error
   error-info:     <bad-element> : name of the element w/ bad value
   Description:    An element value is not correct; e.g., wrong type,
                   out of range, pattern mismatch.

   error-tag:      unknown-element
   error-type:     protocol, application
   error-severity: error
   error-info:     <bad-element> : name of the unexpected element
   Description:    An unexpected element is present.

   error-tag:      unknown-namespace
   error-type:     protocol, application
   error-severity: error
   error-info:     <bad-element> : name of the element that contains
                     the unexpected namespace
                   <bad-namespace> : name of the unexpected namespace
   Description:    An unexpected namespace is present.

   error-tag:      access-denied
   error-type:     protocol, application
   error-severity: error
   error-info:     none
   Description:    Access to the requested protocol operation or
                   data model is denied because authorization failed.
Top   ToC   RFC6241 - Page 78
   error-tag:      lock-denied
   error-type:     protocol
   error-severity: error
   error-info:     <session-id> : session ID of session holding the
                     requested lock, or zero to indicate a non-NETCONF
                     entity holds the lock
   Description:    Access to the requested lock is denied because the
                   lock is currently held by another entity.

   error-tag:      resource-denied
   error-type:     transport, rpc, protocol, application
   error-severity: error
   error-info:     none
   Description:    Request could not be completed because of
                   insufficient resources.

   error-tag:      rollback-failed
   error-type:     protocol, application
   error-severity: error
   error-info:     none
   Description:    Request to roll back some configuration change (via
                   rollback-on-error or <discard-changes> operations)
                   was not completed for some reason.

   error-tag:      data-exists
   error-type:     application
   error-severity: error
   error-info:     none
   Description:    Request could not be completed because the relevant
                   data model content already exists.  For example,
                   a "create" operation was attempted on data that
                   already exists.

   error-tag:      data-missing
   error-type:     application
   error-severity: error
   error-info:     none
   Description:    Request could not be completed because the relevant
                   data model content does not exist.  For example,
                   a "delete" operation was attempted on
                   data that does not exist.

   error-tag:      operation-not-supported
   error-type:     protocol, application
   error-severity: error
   error-info:     none
   Description:    Request could not be completed because the requested
                   operation is not supported by this implementation.
Top   ToC   RFC6241 - Page 79
   error-tag:      operation-failed
   error-type:     rpc, protocol, application
   error-severity: error
   error-info:     none
   Description:    Request could not be completed because the requested
                   operation failed for some reason not covered by
                   any other error condition.

   error-tag:      partial-operation
   error-type:     application
   error-severity: error
   error-info:     <ok-element> : identifies an element in the data
                     model for which the requested operation has been
                     completed for that node and all its child nodes.
                     This element can appear zero or more times in the
                     <error-info> container.

                   <err-element> : identifies an element in the data
                     model for which the requested operation has failed
                     for that node and all its child nodes.
                     This element can appear zero or more times in the
                     <error-info> container.

                   <noop-element> : identifies an element in the data
                     model for which the requested operation was not
                     attempted for that node and all its child nodes.
                     This element can appear zero or more times in the
                     <error-info> container.

   Description:    This error-tag is obsolete, and SHOULD NOT be sent
                   by servers conforming to this document.

                   Some part of the requested operation failed or was
                   not attempted for some reason.  Full cleanup has
                   not been performed (e.g., rollback not supported)
                   by the server.  The error-info container is used
                   to identify which portions of the application
                   data model content for which the requested operation
                   has succeeded (<ok-element>), failed (<bad-element>),
                   or not been attempted (<noop-element>).
Top   ToC   RFC6241 - Page 80
   error-tag:      malformed-message
   error-type:     rpc
   error-severity: error
   error-info:     none
   Description:    A message could not be handled because it failed to
                   be parsed correctly.  For example, the message is not
                   well-formed XML or it uses an invalid character set.

                   This error-tag is new in :base:1.1 and MUST NOT be
                   sent to old clients.

Appendix B. XML Schema for NETCONF Messages Layer

This section is normative. <CODE BEGINS> file "netconf.xsd" <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" targetNamespace="urn:ietf:params:xml:ns:netconf:base:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified" xml:lang="en" version="1.1"> <xs:annotation> <xs:documentation> This schema defines the syntax for the NETCONF Messages layer messages 'hello', 'rpc', and 'rpc-reply'. </xs:documentation> </xs:annotation> <!-- import standard XML definitions --> <xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/xml.xsd"> <xs:annotation> <xs:documentation> This import accesses the xml: attribute groups for the xml:lang as declared on the error-message element. </xs:documentation> </xs:annotation> </xs:import> <!-- message-id attribute -->
Top   ToC   RFC6241 - Page 81
     <xs:simpleType name="messageIdType">
       <xs:restriction base="xs:string">
         <xs:maxLength value="4095"/>
       </xs:restriction>
     </xs:simpleType>
     <!--
        Types used for session-id
       -->
     <xs:simpleType name="SessionId">
       <xs:restriction base="xs:unsignedInt">
         <xs:minInclusive value="1"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:simpleType name="SessionIdOrZero">
       <xs:restriction base="xs:unsignedInt"/>
     </xs:simpleType>
     <!--
        <rpc> element
       -->
     <xs:complexType name="rpcType">
       <xs:sequence>
         <xs:element ref="rpcOperation"/>
       </xs:sequence>
       <xs:attribute name="message-id" type="messageIdType"
                     use="required"/>
       <!--
          Arbitrary attributes can be supplied with <rpc> element.
         -->
       <xs:anyAttribute processContents="lax"/>
     </xs:complexType>
     <xs:element name="rpc" type="rpcType"/>
     <!--
        data types and elements used to construct rpc-errors
       -->
     <xs:simpleType name="ErrorType">
       <xs:restriction base="xs:string">
         <xs:enumeration value="transport"/>
         <xs:enumeration value="rpc"/>
         <xs:enumeration value="protocol"/>
         <xs:enumeration value="application"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:simpleType name="ErrorTag">
       <xs:restriction base="xs:string">
         <xs:enumeration value="in-use"/>
         <xs:enumeration value="invalid-value"/>
         <xs:enumeration value="too-big"/>
         <xs:enumeration value="missing-attribute"/>
Top   ToC   RFC6241 - Page 82
         <xs:enumeration value="bad-attribute"/>
         <xs:enumeration value="unknown-attribute"/>
         <xs:enumeration value="missing-element"/>
         <xs:enumeration value="bad-element"/>
         <xs:enumeration value="unknown-element"/>
         <xs:enumeration value="unknown-namespace"/>
         <xs:enumeration value="access-denied"/>
         <xs:enumeration value="lock-denied"/>
         <xs:enumeration value="resource-denied"/>
         <xs:enumeration value="rollback-failed"/>
         <xs:enumeration value="data-exists"/>
         <xs:enumeration value="data-missing"/>
         <xs:enumeration value="operation-not-supported"/>
         <xs:enumeration value="operation-failed"/>
         <xs:enumeration value="partial-operation"/>
         <xs:enumeration value="malformed-message"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:simpleType name="ErrorSeverity">
       <xs:restriction base="xs:string">
         <xs:enumeration value="error"/>
         <xs:enumeration value="warning"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:complexType name="errorInfoType">
       <xs:sequence>
         <xs:choice>
           <xs:element name="session-id" type="SessionIdOrZero"/>
           <xs:sequence minOccurs="0" maxOccurs="unbounded">
             <xs:sequence>
               <xs:element name="bad-attribute" type="xs:QName"
                           minOccurs="0" maxOccurs="1"/>
               <xs:element name="bad-element" type="xs:QName"
                           minOccurs="0" maxOccurs="1"/>
               <xs:element name="ok-element" type="xs:QName"
                           minOccurs="0" maxOccurs="1"/>
               <xs:element name="err-element" type="xs:QName"
                           minOccurs="0" maxOccurs="1"/>
               <xs:element name="noop-element" type="xs:QName"
                           minOccurs="0" maxOccurs="1"/>
               <xs:element name="bad-namespace" type="xs:string"
                           minOccurs="0" maxOccurs="1"/>
             </xs:sequence>
           </xs:sequence>
         </xs:choice>
         <!-- elements from any other namespace are also allowed
              to follow the NETCONF elements -->
         <xs:any namespace="##other" processContents="lax"
Top   ToC   RFC6241 - Page 83
                 minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:complexType>
     <xs:complexType name="rpcErrorType">
       <xs:sequence>
         <xs:element name="error-type" type="ErrorType"/>
         <xs:element name="error-tag" type="ErrorTag"/>
         <xs:element name="error-severity" type="ErrorSeverity"/>
         <xs:element name="error-app-tag" type="xs:string"
                     minOccurs="0"/>
         <xs:element name="error-path" type="xs:string" minOccurs="0"/>
         <xs:element name="error-message" minOccurs="0">
           <xs:complexType>
             <xs:simpleContent>
               <xs:extension base="xs:string">
                 <xs:attribute ref="xml:lang" use="optional"/>
               </xs:extension>
             </xs:simpleContent>
           </xs:complexType>
         </xs:element>
         <xs:element name="error-info" type="errorInfoType"
                     minOccurs="0"/>
       </xs:sequence>
     </xs:complexType>
     <!--
        operation attribute used in <edit-config>
       -->
     <xs:simpleType name="editOperationType">
       <xs:restriction base="xs:string">
         <xs:enumeration value="merge"/>
         <xs:enumeration value="replace"/>
         <xs:enumeration value="create"/>
         <xs:enumeration value="delete"/>
         <xs:enumeration value="remove"/>
       </xs:restriction>
     </xs:simpleType>
     <xs:attribute name="operation" type="editOperationType"/>
     <!--
        <rpc-reply> element
       -->
     <xs:complexType name="rpcReplyType">
       <xs:choice>
         <xs:element name="ok"/>
         <xs:sequence>
           <xs:element ref="rpc-error"
                       minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="rpcResponse"
                       minOccurs="0" maxOccurs="unbounded"/>
Top   ToC   RFC6241 - Page 84
         </xs:sequence>
       </xs:choice>
       <xs:attribute name="message-id" type="messageIdType"
                     use="optional"/>
       <!--
          Any attributes supplied with <rpc> element must be returned
          on <rpc-reply>.
         -->
       <xs:anyAttribute processContents="lax"/>
     </xs:complexType>
     <xs:element name="rpc-reply" type="rpcReplyType"/>
     <!--
        <rpc-error> element
          -->
     <xs:element name="rpc-error" type="rpcErrorType"/>
     <!--
        rpcOperationType: used as a base type for all
        NETCONF operations
       -->
     <xs:complexType name="rpcOperationType"/>
     <xs:element name="rpcOperation" type="rpcOperationType"
                 abstract="true"/>
     <!--
        rpcResponseType: used as a base type for all
        NETCONF responses
       -->
     <xs:complexType name="rpcResponseType"/>
     <xs:element name="rpcResponse" type="rpcResponseType"
                 abstract="true"/>
     <!--
        <hello> element
       -->
     <xs:element name="hello">
       <xs:complexType>
         <xs:sequence>
           <xs:element name="capabilities">
             <xs:complexType>
               <xs:sequence>
                 <xs:element name="capability" type="xs:anyURI"
                             maxOccurs="unbounded"/>
               </xs:sequence>
             </xs:complexType>
           </xs:element>
           <xs:element name="session-id" type="SessionId"
                       minOccurs="0"/>
Top   ToC   RFC6241 - Page 85
         </xs:sequence>
       </xs:complexType>
     </xs:element>
   </xs:schema>

   <CODE ENDS>



(page 85 continued on part 5)

Next Section