tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6241

 
 
 

Network Configuration Protocol (NETCONF)

Part 4 of 5, p. 61 to 85
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 61 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       Page 85 
         </xs:sequence>
       </xs:complexType>
     </xs:element>
   </xs:schema>

   <CODE ENDS>



(page 85 continued on part 5)

Next RFC Part