tech-invite   World Map     

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

RFC 6241

 Errata 
Proposed STD
Pages: 113
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: NETCONF

Network Configuration Protocol (NETCONF)

Part 1 of 5, p. 1 to 13
None       Next RFC Part

Obsoletes:    4741
Updated by:    7803


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                      R. Enns, Ed.
Request for Comments: 6241                              Juniper Networks
Obsoletes: 4741                                        M. Bjorklund, Ed.
Category: Standards Track                                 Tail-f Systems
ISSN: 2070-1721                                    J. Schoenwaelder, Ed.
                                                       Jacobs University
                                                         A. Bierman, Ed.
                                                                 Brocade
                                                               June 2011


                Network Configuration Protocol (NETCONF)

Abstract

   The Network Configuration Protocol (NETCONF) defined in this document
   provides mechanisms to install, manipulate, and delete the
   configuration of network devices.  It uses an Extensible Markup
   Language (XML)-based data encoding for the configuration data as well
   as the protocol messages.  The NETCONF protocol operations are
   realized as remote procedure calls (RPCs).  This document obsoletes
   RFC 4741.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6241.

Page 2 
Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Top       Page 3 
Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   6
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   7
     1.2.  Protocol Overview . . . . . . . . . . . . . . . . . . . .   8
     1.3.  Capabilities  . . . . . . . . . . . . . . . . . . . . . .  10
     1.4.  Separation of Configuration and State Data  . . . . . . .  10
   2.  Transport Protocol Requirements . . . . . . . . . . . . . . .  11
     2.1.  Connection-Oriented Operation . . . . . . . . . . . . . .  11
     2.2.  Authentication, Integrity, and Confidentiality  . . . . .  12
     2.3.  Mandatory Transport Protocol  . . . . . . . . . . . . . .  12
   3.  XML Considerations  . . . . . . . . . . . . . . . . . . . . .  13
     3.1.  Namespace . . . . . . . . . . . . . . . . . . . . . . . .  13
     3.2.  Document Type Declarations  . . . . . . . . . . . . . . .  13
   4.  RPC Model . . . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.1.  <rpc> Element . . . . . . . . . . . . . . . . . . . . . .  13
     4.2.  <rpc-reply> Element . . . . . . . . . . . . . . . . . . .  15
     4.3.  <rpc-error> Element . . . . . . . . . . . . . . . . . . .  16
     4.4.  <ok> Element  . . . . . . . . . . . . . . . . . . . . . .  19
     4.5.  Pipelining  . . . . . . . . . . . . . . . . . . . . . . .  19
   5.  Configuration Model . . . . . . . . . . . . . . . . . . . . .  19
     5.1.  Configuration Datastores  . . . . . . . . . . . . . . . .  19
     5.2.  Data Modeling . . . . . . . . . . . . . . . . . . . . . .  20
   6.  Subtree Filtering . . . . . . . . . . . . . . . . . . . . . .  20
     6.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .  20
     6.2.  Subtree Filter Components . . . . . . . . . . . . . . . .  21
       6.2.1.  Namespace Selection . . . . . . . . . . . . . . . . .  21
       6.2.2.  Attribute Match Expressions . . . . . . . . . . . . .  22
       6.2.3.  Containment Nodes . . . . . . . . . . . . . . . . . .  23
       6.2.4.  Selection Nodes . . . . . . . . . . . . . . . . . . .  23
       6.2.5.  Content Match Nodes . . . . . . . . . . . . . . . . .  24
     6.3.  Subtree Filter Processing . . . . . . . . . . . . . . . .  25
     6.4.  Subtree Filtering Examples  . . . . . . . . . . . . . . .  26
       6.4.1.  No Filter . . . . . . . . . . . . . . . . . . . . . .  26
       6.4.2.  Empty Filter  . . . . . . . . . . . . . . . . . . . .  26
       6.4.3.  Select the Entire <users> Subtree . . . . . . . . . .  27
       6.4.4.  Select All <name> Elements within the <users>
               Subtree . . . . . . . . . . . . . . . . . . . . . . .  29
       6.4.5.  One Specific <user> Entry . . . . . . . . . . . . . .  30
       6.4.6.  Specific Elements from a Specific <user> Entry  . . .  31
       6.4.7.  Multiple Subtrees . . . . . . . . . . . . . . . . . .  32
       6.4.8.  Elements with Attribute Naming  . . . . . . . . . . .  33
   7.  Protocol Operations . . . . . . . . . . . . . . . . . . . . .  35
     7.1.  <get-config>  . . . . . . . . . . . . . . . . . . . . . .  35
     7.2.  <edit-config> . . . . . . . . . . . . . . . . . . . . . .  37
     7.3.  <copy-config> . . . . . . . . . . . . . . . . . . . . . .  43
     7.4.  <delete-config> . . . . . . . . . . . . . . . . . . . . .  44
     7.5.  <lock>  . . . . . . . . . . . . . . . . . . . . . . . . .  44

Top      ToC       Page 4 
     7.6.  <unlock>  . . . . . . . . . . . . . . . . . . . . . . . .  47
     7.7.  <get> . . . . . . . . . . . . . . . . . . . . . . . . . .  48
     7.8.  <close-session> . . . . . . . . . . . . . . . . . . . . .  49
     7.9.  <kill-session>  . . . . . . . . . . . . . . . . . . . . .  50
   8.  Capabilities  . . . . . . . . . . . . . . . . . . . . . . . .  51
     8.1.  Capabilities Exchange . . . . . . . . . . . . . . . . . .  51
     8.2.  Writable-Running Capability . . . . . . . . . . . . . . .  53
       8.2.1.  Description . . . . . . . . . . . . . . . . . . . . .  53
       8.2.2.  Dependencies  . . . . . . . . . . . . . . . . . . . .  53
       8.2.3.  Capability Identifier . . . . . . . . . . . . . . . .  53
       8.2.4.  New Operations  . . . . . . . . . . . . . . . . . . .  53
       8.2.5.  Modifications to Existing Operations  . . . . . . . .  53
     8.3.  Candidate Configuration Capability  . . . . . . . . . . .  53
       8.3.1.  Description . . . . . . . . . . . . . . . . . . . . .  53
       8.3.2.  Dependencies  . . . . . . . . . . . . . . . . . . . .  54
       8.3.3.  Capability Identifier . . . . . . . . . . . . . . . .  54
       8.3.4.  New Operations  . . . . . . . . . . . . . . . . . . .  54
       8.3.5.  Modifications to Existing Operations  . . . . . . . .  56
     8.4.  Confirmed Commit Capability . . . . . . . . . . . . . . .  57
       8.4.1.  Description . . . . . . . . . . . . . . . . . . . . .  57
       8.4.2.  Dependencies  . . . . . . . . . . . . . . . . . . . .  58
       8.4.3.  Capability Identifier . . . . . . . . . . . . . . . .  58
       8.4.4.  New Operations  . . . . . . . . . . . . . . . . . . .  59
       8.4.5.  Modifications to Existing Operations  . . . . . . . .  60
     8.5.  Rollback-on-Error Capability  . . . . . . . . . . . . . .  61
       8.5.1.  Description . . . . . . . . . . . . . . . . . . . . .  61
       8.5.2.  Dependencies  . . . . . . . . . . . . . . . . . . . .  62
       8.5.3.  Capability Identifier . . . . . . . . . . . . . . . .  62
       8.5.4.  New Operations  . . . . . . . . . . . . . . . . . . .  62
       8.5.5.  Modifications to Existing Operations  . . . . . . . .  62
     8.6.  Validate Capability . . . . . . . . . . . . . . . . . . .  63
       8.6.1.  Description . . . . . . . . . . . . . . . . . . . . .  63
       8.6.2.  Dependencies  . . . . . . . . . . . . . . . . . . . .  63
       8.6.3.  Capability Identifier . . . . . . . . . . . . . . . .  63
       8.6.4.  New Operations  . . . . . . . . . . . . . . . . . . .  63
       8.6.5.  Modifications to Existing Operations  . . . . . . . .  64
     8.7.  Distinct Startup Capability . . . . . . . . . . . . . . .  64
       8.7.1.  Description . . . . . . . . . . . . . . . . . . . . .  64
       8.7.2.  Dependencies  . . . . . . . . . . . . . . . . . . . .  65
       8.7.3.  Capability Identifier . . . . . . . . . . . . . . . .  65
       8.7.4.  New Operations  . . . . . . . . . . . . . . . . . . .  65
       8.7.5.  Modifications to Existing Operations  . . . . . . . .  65
     8.8.  URL Capability  . . . . . . . . . . . . . . . . . . . . .  66
       8.8.1.  Description . . . . . . . . . . . . . . . . . . . . .  66
       8.8.2.  Dependencies  . . . . . . . . . . . . . . . . . . . .  66
       8.8.3.  Capability Identifier . . . . . . . . . . . . . . . .  66
       8.8.4.  New Operations  . . . . . . . . . . . . . . . . . . .  66
       8.8.5.  Modifications to Existing Operations  . . . . . . . .  66

Top      ToC       Page 5 
     8.9.  XPath Capability  . . . . . . . . . . . . . . . . . . . .  67
       8.9.1.  Description . . . . . . . . . . . . . . . . . . . . .  67
       8.9.2.  Dependencies  . . . . . . . . . . . . . . . . . . . .  68
       8.9.3.  Capability Identifier . . . . . . . . . . . . . . . .  68
       8.9.4.  New Operations  . . . . . . . . . . . . . . . . . . .  68
       8.9.5.  Modifications to Existing Operations  . . . . . . . .  68
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  69
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  71
     10.1. NETCONF XML Namespace . . . . . . . . . . . . . . . . . .  71
     10.2. NETCONF XML Schema  . . . . . . . . . . . . . . . . . . .  71
     10.3. NETCONF YANG Module . . . . . . . . . . . . . . . . . . .  72
     10.4. NETCONF Capability URNs . . . . . . . . . . . . . . . . .  72
   11. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  73
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  73
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  74
     13.1. Normative References  . . . . . . . . . . . . . . . . . .  74
     13.2. Informative References  . . . . . . . . . . . . . . . . .  75
   Appendix A.  NETCONF Error List . . . . . . . . . . . . . . . . .  76
   Appendix B.  XML Schema for NETCONF Messages Layer  . . . . . . .  80
   Appendix C.  YANG Module for NETCONF Protocol Operations  . . . .  85
   Appendix D.  Capability Template  . . . . . . . . . . . . . . . . 105
     D.1.  capability-name (template)  . . . . . . . . . . . . . . . 105
       D.1.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . 105
       D.1.2.  Dependencies  . . . . . . . . . . . . . . . . . . . . 105
       D.1.3.  Capability Identifier . . . . . . . . . . . . . . . . 105
       D.1.4.  New Operations  . . . . . . . . . . . . . . . . . . . 105
       D.1.5.  Modifications to Existing Operations  . . . . . . . . 105
       D.1.6.  Interactions with Other Capabilities  . . . . . . . . 105
   Appendix E.  Configuring Multiple Devices with NETCONF  . . . . . 106
     E.1.  Operations on Individual Devices  . . . . . . . . . . . . 106
       E.1.1.  Acquiring the Configuration Lock  . . . . . . . . . . 106
       E.1.2.  Checkpointing the Running Configuration . . . . . . . 107
       E.1.3.  Loading and Validating the Incoming Configuration . . 108
       E.1.4.  Changing the Running Configuration  . . . . . . . . . 108
       E.1.5.  Testing the New Configuration . . . . . . . . . . . . 109
       E.1.6.  Making the Change Permanent . . . . . . . . . . . . . 109
       E.1.7.  Releasing the Configuration Lock  . . . . . . . . . . 110
     E.2.  Operations on Multiple Devices  . . . . . . . . . . . . . 111
   Appendix F.  Changes from RFC 4741  . . . . . . . . . . . . . . . 112

Top      ToC       Page 6 
1.  Introduction

   The NETCONF protocol defines a simple mechanism through which a
   network device can be managed, configuration data information can be
   retrieved, and new configuration data can be uploaded and
   manipulated.  The protocol allows the device to expose a full, formal
   application programming interface (API).  Applications can use this
   straightforward API to send and receive full and partial
   configuration data sets.

   The NETCONF protocol uses a remote procedure call (RPC) paradigm.  A
   client encodes an RPC in XML [W3C.REC-xml-20001006] and sends it to a
   server using a secure, connection-oriented session.  The server
   responds with a reply encoded in XML.  The contents of both the
   request and the response are fully described in XML DTDs or XML
   schemas, or both, allowing both parties to recognize the syntax
   constraints imposed on the exchange.

   A key aspect of NETCONF is that it allows the functionality of the
   management protocol to closely mirror the native functionality of the
   device.  This reduces implementation costs and allows timely access
   to new features.  In addition, applications can access both the
   syntactic and semantic content of the device's native user interface.

   NETCONF allows a client to discover the set of protocol extensions
   supported by a server.  These "capabilities" permit the client to
   adjust its behavior to take advantage of the features exposed by the
   device.  The capability definitions can be easily extended in a
   noncentralized manner.  Standard and non-standard capabilities can be
   defined with semantic and syntactic rigor.  Capabilities are
   discussed in Section 8.

   The NETCONF protocol is a building block in a system of automated
   configuration.  XML is the lingua franca of interchange, providing a
   flexible but fully specified encoding mechanism for hierarchical
   content.  NETCONF can be used in concert with XML-based
   transformation technologies, such as XSLT [W3C.REC-xslt-19991116], to
   provide a system for automated generation of full and partial
   configurations.  The system can query one or more databases for data
   about networking topologies, links, policies, customers, and
   services.  This data can be transformed using one or more XSLT
   scripts from a task-oriented, vendor-independent data schema into a
   form that is specific to the vendor, product, operating system, and
   software release.  The resulting data can be passed to the device
   using the NETCONF protocol.

Top      ToC       Page 7 
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

1.1.  Terminology

   o  candidate configuration datastore: A configuration datastore that
      can be manipulated without impacting the device's current
      configuration and that can be committed to the running
      configuration datastore.  Not all devices support a candidate
      configuration datastore.

   o  capability: A functionality that supplements the base NETCONF
      specification.

   o  client: Invokes protocol operations on a server.  In addition, a
      client can subscribe to receive notifications from a server.

   o  configuration data: The set of writable data that is required to
      transform a system from its initial default state into its current
      state.

   o  datastore: A conceptual place to store and access information.  A
      datastore might be implemented, for example, using files, a
      database, flash memory locations, or combinations thereof.

   o  configuration datastore: The datastore holding the complete set of
      configuration data that is required to get a device from its
      initial default state into a desired operational state.

   o  message: A protocol element sent over a session.  Messages are
      well-formed XML documents.

   o  notification: A server-initiated message indicating that a certain
      event has been recognized by the server.

   o  protocol operation: A specific remote procedure call, as used
      within the NETCONF protocol.

   o  remote procedure call (RPC): Realized by exchanging <rpc> and
      <rpc-reply> messages.

   o  running configuration datastore: A configuration datastore holding
      the complete configuration currently active on the device.  The
      running configuration datastore always exists.

   o  server: Executes protocol operations invoked by a client.  In
      addition, a server can send notifications to a client.

Top      ToC       Page 8 
   o  session: Client and server exchange messages using a secure,
      connection-oriented session.

   o  startup configuration datastore: The configuration datastore
      holding the configuration loaded by the device when it boots.
      Only present on devices that separate the startup configuration
      datastore from the running configuration datastore.

   o  state data: The additional data on a system that is not
      configuration data such as read-only status information and
      collected statistics.

   o  user: The authenticated identity of the client.  The authenticated
      identity of a client is commonly referred to as the NETCONF
      username.

1.2.  Protocol Overview

   NETCONF uses a simple RPC-based mechanism to facilitate communication
   between a client and a server.  The client can be a script or
   application typically running as part of a network manager.  The
   server is typically a network device.  The terms "device" and
   "server" are used interchangeably in this document, as are "client"
   and "application".

   A NETCONF session is the logical connection between a network
   administrator or network configuration application and a network
   device.  A device MUST support at least one NETCONF session and
   SHOULD support multiple sessions.  Global configuration attributes
   can be changed during any authorized session, and the effects are
   visible in all sessions.  Session-specific attributes affect only the
   session in which they are changed.

   NETCONF can be conceptually partitioned into four layers as shown in
   Figure 1.

Top      ToC       Page 9 
            Layer                 Example
       +-------------+      +-----------------+      +----------------+
   (4) |   Content   |      |  Configuration  |      |  Notification  |
       |             |      |      data       |      |      data      |
       +-------------+      +-----------------+      +----------------+
              |                       |                      |
       +-------------+      +-----------------+              |
   (3) | Operations  |      |  <edit-config>  |              |
       |             |      |                 |              |
       +-------------+      +-----------------+              |
              |                       |                      |
       +-------------+      +-----------------+      +----------------+
   (2) |  Messages   |      |     <rpc>,      |      | <notification> |
       |             |      |   <rpc-reply>   |      |                |
       +-------------+      +-----------------+      +----------------+
              |                       |                      |
       +-------------+      +-----------------------------------------+
   (1) |   Secure    |      |  SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... |
       |  Transport  |      |                                         |
       +-------------+      +-----------------------------------------+

                     Figure 1: NETCONF Protocol Layers

   (1)  The Secure Transport layer provides a communication path between
        the client and server.  NETCONF can be layered over any
        transport protocol that provides a set of basic requirements.
        Section 2 discusses these requirements.

   (2)  The Messages layer provides a simple, transport-independent
        framing mechanism for encoding RPCs and notifications.
        Section 4 documents the RPC messages, and [RFC5717] documents
        notifications.

   (3)  The Operations layer defines a set of base protocol operations
        invoked as RPC methods with XML-encoded parameters.  Section 7
        details the list of base protocol operations.

   (4)  The Content layer is outside the scope of this document.  It is
        expected that separate efforts to standardize NETCONF data
        models will be undertaken.

   The YANG data modeling language [RFC6020] has been developed for
   specifying NETCONF data models and protocol operations, covering the
   Operations and the Content layers of Figure 1.

Top      ToC       Page 10 
1.3.  Capabilities

   A NETCONF capability is a set of functionality that supplements the
   base NETCONF specification.  The capability is identified by a
   uniform resource identifier (URI) [RFC3986].

   Capabilities augment the base operations of the device, describing
   both additional operations and the content allowed inside operations.
   The client can discover the server's capabilities and use any
   additional operations, parameters, and content defined by those
   capabilities.

   The capability definition might name one or more dependent
   capabilities.  To support a capability, the server MUST support any
   capabilities upon which it depends.

   Section 8 defines the capabilities exchange that allows the client to
   discover the server's capabilities.  Section 8 also lists the set of
   capabilities defined in this document.

   Additional capabilities can be defined at any time in external
   documents, allowing the set of capabilities to expand over time.
   Standards bodies can define standardized capabilities, and
   implementations can define proprietary ones.  A capability URI MUST
   sufficiently distinguish the naming authority to avoid naming
   collisions.

1.4.  Separation of Configuration and State Data

   The information that can be retrieved from a running system is
   separated into two classes, configuration data and state data.
   Configuration data is the set of writable data that is required to
   transform a system from its initial default state into its current
   state.  State data is the additional data on a system that is not
   configuration data such as read-only status information and collected
   statistics.  When a device is performing configuration operations, a
   number of problems would arise if state data were included:

   o  Comparisons of configuration data sets would be dominated by
      irrelevant entries such as different statistics.

   o  Incoming data could contain nonsensical requests, such as attempts
      to write read-only data.

   o  The data sets would be large.

   o  Archived data could contain values for read-only data items,
      complicating the processing required to restore archived data.

Top      ToC       Page 11 
   To account for these issues, the NETCONF protocol recognizes the
   difference between configuration data and state data and provides
   operations for each.  The <get-config> operation retrieves
   configuration data only, while the <get> operation retrieves
   configuration and state data.

   Note that the NETCONF protocol is focused on the information required
   to get the device into its desired running state.  The inclusion of
   other important, persistent data is implementation specific.  For
   example, user files and databases are not treated as configuration
   data by the NETCONF protocol.

   For example, if a local database of user authentication data is
   stored on the device, it is an implementation-dependent matter
   whether it is included in configuration data.

2.  Transport Protocol Requirements

   NETCONF uses an RPC-based communication paradigm.  A client sends a
   series of one or more RPC request messages, which cause the server to
   respond with a corresponding series of RPC reply messages.

   The NETCONF protocol can be layered on any transport protocol that
   provides the required set of functionality.  It is not bound to any
   particular transport protocol, but allows a mapping to define how it
   can be implemented over any specific protocol.

   The transport protocol MUST provide a mechanism to indicate the
   session type (client or server) to the NETCONF protocol layer.

   This section details the characteristics that NETCONF requires from
   the underlying transport protocol.

2.1.  Connection-Oriented Operation

   NETCONF is connection-oriented, requiring a persistent connection
   between peers.  This connection MUST provide reliable, sequenced data
   delivery.  NETCONF connections are long-lived, persisting between
   protocol operations.

   In addition, resources requested from the server for a particular
   connection MUST be automatically released when the connection closes,
   making failure recovery simpler and more robust.  For example, when a
   lock is acquired by a client, the lock persists until either it is
   explicitly released or the server determines that the connection has
   been terminated.  If a connection is terminated while the client
   holds a lock, the server can perform any appropriate recovery.  The
   <lock> operation is further discussed in Section 7.5.

Top      ToC       Page 12 
2.2.  Authentication, Integrity, and Confidentiality

   NETCONF connections MUST provide authentication, data integrity,
   confidentiality, and replay protection.  NETCONF depends on the
   transport protocol for this capability.  A NETCONF peer assumes that
   appropriate levels of security and confidentiality are provided
   independently of this document.  For example, connections could be
   encrypted using Transport Layer Security (TLS) [RFC5246] or Secure
   Shell (SSH) [RFC4251], depending on the underlying protocol.

   NETCONF connections MUST be authenticated.  The transport protocol is
   responsible for authentication of the server to the client and
   authentication of the client to the server.  A NETCONF peer assumes
   that the connection's authentication information has been validated
   by the underlying transport protocol using sufficiently trustworthy
   mechanisms and that the peer's identity has been sufficiently proven.

   One goal of NETCONF is to provide a programmatic interface to the
   device that closely follows the functionality of the device's native
   interface.  Therefore, it is expected that the underlying protocol
   uses existing authentication mechanisms available on the device.  For
   example, a NETCONF server on a device that supports RADIUS [RFC2865]
   might allow the use of RADIUS to authenticate NETCONF sessions.

   The authentication process MUST result in an authenticated client
   identity whose permissions are known to the server.  The
   authenticated identity of a client is commonly referred to as the
   NETCONF username.  The username is a string of characters that match
   the "Char" production from Section 2.2 of [W3C.REC-xml-20001006].
   The algorithm used to derive the username is transport protocol
   specific and in addition specific to the authentication mechanism
   used by the transport protocol.  The transport protocol MUST provide
   a username to be used by the other NETCONF layers.

   The access permissions of a given client, identified by its NETCONF
   username, are part of the configuration of the NETCONF server.  These
   permissions MUST be enforced during the remainder of the NETCONF
   session.  The details of how access control is configured is outside
   the scope of this document.

2.3.  Mandatory Transport Protocol

   A NETCONF implementation MUST support the SSH transport protocol
   mapping [RFC6242].

Top      ToC       Page 13 
3.  XML Considerations

   XML serves as the encoding format for NETCONF, allowing complex
   hierarchical data to be expressed in a text format that can be read,
   saved, and manipulated with both traditional text tools and tools
   specific to XML.

   All NETCONF messages MUST be well-formed XML, encoded in UTF-8
   [RFC3629].  If a peer receives an <rpc> message that is not well-
   formed XML or not encoded in UTF-8, it SHOULD reply with a
   "malformed-message" error.  If a reply cannot be sent for any reason,
   the server MUST terminate the session.

   A NETCONF message MAY begin with an XML declaration (see Section 2.8
   of [W3C.REC-xml-20001006]).

   This section discusses a small number of XML-related considerations
   pertaining to NETCONF.

3.1.  Namespace

   All NETCONF protocol elements are defined in the following namespace:

      urn:ietf:params:xml:ns:netconf:base:1.0

   NETCONF capability names MUST be URIs [RFC3986].  NETCONF
   capabilities are discussed in Section 8.

3.2.  Document Type Declarations

   Document type declarations (see Section 2.8 of
   [W3C.REC-xml-20001006]) MUST NOT appear in NETCONF content.



(page 13 continued on part 2)

Next RFC Part