idnits 2.17.1 draft-ietf-netconf-prot-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 35 instances of too long lines in the document, the longest one being 11 characters in excess of 72. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 261 has weird spacing: '... set of funct...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 11, 2003) is 7565 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Optional' on line 1856 == Unused Reference: '3' is defined on line 2540, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2559, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2563, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 2565, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2222 (ref. '3') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2246 (ref. '4') (Obsoleted by RFC 4346) == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-13 Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Enns, Editor 3 Internet-Draft Juniper Networks 4 Expires: February 9, 2004 August 11, 2003 6 NETCONF Configuration Protocol 7 draft-ietf-netconf-prot-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on February 9, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 There is a need for standardized mechanisms to manipulate, install, 39 edit, and delete the configuration of a network device. In addition, 40 there is a need to retrieve device state information and receive 41 asynchronous device state messages in a manner consistent with the 42 configuration mechanisms. There is great interest in using an 43 XML-based data encoding because a significant set of tools for 44 manipulating ASCII text and XML encoded data already exists. 46 Please send comments to netconf@ops.ietf.org. To subscribe, use 47 netconf-request@ops.ietf.org. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 52 1.1 Protocol Overview . . . . . . . . . . . . . . . . . . . . . 6 53 1.1.1 Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 7 54 1.2 Separation of Configuration and State Data . . . . . . . . . 7 55 1.3 Executive Commands . . . . . . . . . . . . . . . . . . . . . 8 56 1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 8 57 1.4.1 Configuration Session . . . . . . . . . . . . . . . . . . . 8 58 2. Transport Protocol Requirements . . . . . . . . . . . . . . 9 59 2.1 Connection-oriented operation . . . . . . . . . . . . . . . 9 60 2.2 Security and Privacy . . . . . . . . . . . . . . . . . . . . 9 61 2.3 Authentication . . . . . . . . . . . . . . . . . . . . . . . 9 62 2.4 Channels . . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 2.4.1 Management Channel . . . . . . . . . . . . . . . . . . . . . 10 64 2.4.2 Operation Channel . . . . . . . . . . . . . . . . . . . . . 11 65 2.4.3 Notification Channel . . . . . . . . . . . . . . . . . . . . 11 66 3. RPC Model . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 3.1 Namespace . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 3.2 Element . . . . . . . . . . . . . . . . . . . . . . . 12 69 3.3 Element . . . . . . . . . . . . . . . . . . . . 13 70 3.4 Element . . . . . . . . . . . . . . . . . . . . 13 71 3.5 Element . . . . . . . . . . . . . . . . . 14 72 3.6 Element . . . . . . . . . . . . . . . . . . . . 14 73 3.7 Element . . . . . . . . . . . . . . . . . . . . . . . . 15 74 3.8 Element . . . . . . . . . . . . . . . . . . . 15 75 3.9 Pipelining . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 4. Configuration Model . . . . . . . . . . . . . . . . . . . . 17 77 4.1 Configuration Datastores . . . . . . . . . . . . . . . . . . 17 78 5. Protocol Operations . . . . . . . . . . . . . . . . . . . . 18 79 5.1 . . . . . . . . . . . . . . . . . . . . . . . . 18 80 5.2 . . . . . . . . . . . . . . . . . . . . . . . 21 81 5.3 . . . . . . . . . . . . . . . . . . . . . . . 25 82 5.4 . . . . . . . . . . . . . . . . . . . . . . 27 83 5.5 . . . . . . . . . . . . . . . . . . . . . . . . 28 84 5.6 . . . . . . . . . . . . . . . . . . . . . . . 29 85 6. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 31 86 6.1 Capabilities Exchange . . . . . . . . . . . . . . . . . . . 31 87 6.2 Writable-Running Capability . . . . . . . . . . . . . . . . 32 88 6.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 32 89 6.2.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 32 90 6.2.3 Capability and Namespace . . . . . . . . . . . . . . . . . . 32 91 6.2.4 New Operations . . . . . . . . . . . . . . . . . . . . . . . 32 92 6.2.5 Modifications to Existing Operations . . . . . . . . . . . . 32 93 6.3 Candidate Configuration Capability . . . . . . . . . . . . . 33 94 6.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 33 95 6.3.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 33 96 6.3.3 Capability and Namespace . . . . . . . . . . . . . . . . . . 34 97 6.3.4 New Operations . . . . . . . . . . . . . . . . . . . . . . . 34 98 6.3.5 Modifications to Existing Operations . . . . . . . . . . . . 35 99 6.4 Validate Capability . . . . . . . . . . . . . . . . . . . . 37 100 6.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 37 101 6.4.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 37 102 6.4.3 Capability and Namespace . . . . . . . . . . . . . . . . . . 37 103 6.4.4 New Operations . . . . . . . . . . . . . . . . . . . . . . . 37 104 6.5 Distinct Startup Capability . . . . . . . . . . . . . . . . 38 105 6.5.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 38 106 6.5.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 38 107 6.5.3 Capability and Namespace . . . . . . . . . . . . . . . . . . 38 108 6.5.4 New Operations . . . . . . . . . . . . . . . . . . . . . . . 39 109 6.5.5 Modifications to Existing Operations . . . . . . . . . . . . 39 110 6.6 Lock Capability . . . . . . . . . . . . . . . . . . . . . . 39 111 6.6.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 39 112 6.6.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 40 113 6.6.3 Capability and Namespace . . . . . . . . . . . . . . . . . . 40 114 6.6.4 New Operations . . . . . . . . . . . . . . . . . . . . . . . 40 115 6.7 Notifications Capability . . . . . . . . . . . . . . . . . . 42 116 6.7.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 43 117 6.7.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 43 118 6.7.3 Capability and Namespace . . . . . . . . . . . . . . . . . . 43 119 6.7.4 New Operations . . . . . . . . . . . . . . . . . . . . . . . 43 120 6.8 URL Capability . . . . . . . . . . . . . . . . . . . . . . . 45 121 6.8.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 45 122 6.8.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 45 123 6.8.3 Capability and Namespace . . . . . . . . . . . . . . . . . . 45 124 6.8.4 New Operations . . . . . . . . . . . . . . . . . . . . . . . 45 125 6.8.5 Modifications to Existing Operations . . . . . . . . . . . . 45 126 7. XML Usage Guidelines for NETCONF . . . . . . . . . . . . . . 47 127 7.1 No DTDs . . . . . . . . . . . . . . . . . . . . . . . . . . 47 128 7.2 Avoid Mixed Content . . . . . . . . . . . . . . . . . . . . 47 129 7.3 No Attributes in the Default Namespace . . . . . . . . . . . 47 130 7.4 Use Container Elements for Lists . . . . . . . . . . . . . . 48 131 7.5 Elements and Attributes . . . . . . . . . . . . . . . . . . 48 132 7.5.1 Consider Attributes as Metadata . . . . . . . . . . . . . . 48 133 7.5.2 Consider the Lack of Extensibility of Attributes . . . . . . 48 134 7.6 Proper Tag Names . . . . . . . . . . . . . . . . . . . . . . 48 135 7.7 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 49 136 8. XML Schema for NETCONF RPC and Protocol Operations . . . . . 51 137 9. XML Schema for NETCONF State Data . . . . . . . . . . . . . 57 138 10. Security Considerations . . . . . . . . . . . . . . . . . . 60 139 11. Authors and Acknowledgements . . . . . . . . . . . . . . . . 61 140 Normative References . . . . . . . . . . . . . . . . . . . . 62 141 Informative References . . . . . . . . . . . . . . . . . . . 63 142 Author's Address . . . . . . . . . . . . . . . . . . . . . . 63 143 A. Capability Template . . . . . . . . . . . . . . . . . . . . 64 144 A.1 capability-name (template) . . . . . . . . . . . . . . . . . 64 145 A.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 64 146 A.1.2 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 64 147 A.1.3 Capability and Namespace . . . . . . . . . . . . . . . . . . 64 148 A.1.4 New Operations . . . . . . . . . . . . . . . . . . . . . . . 64 149 A.1.5 Modifications to Existing Operations . . . . . . . . . . . . 64 150 A.1.6 Interactions with Other Capabilities . . . . . . . . . . . . 64 151 B. Configuring Multiple Devices with NETCONF . . . . . . . . . 65 152 B.1 Operations on Individual Devices . . . . . . . . . . . . . . 65 153 B.1.1 Acquiring the Configuration Lock . . . . . . . . . . . . . . 65 154 B.1.2 Loading the Update . . . . . . . . . . . . . . . . . . . . . 66 155 B.1.3 Validating the Incoming Configuration . . . . . . . . . . . 67 156 B.1.4 Checkpointing the Running Configuration . . . . . . . . . . 68 157 B.1.5 Changing the Running Configuration . . . . . . . . . . . . . 68 158 B.1.6 Testing the New Configuration . . . . . . . . . . . . . . . 69 159 B.1.7 Making the Change Permanent . . . . . . . . . . . . . . . . 69 160 B.1.8 Releasing the Configuration Lock . . . . . . . . . . . . . . 70 161 B.2 Operations on Multiple Devices . . . . . . . . . . . . . . . 70 162 Intellectual Property and Copyright Statements . . . . . . . 72 164 1. Introduction 166 The NETCONF protocol defines a simple mechanism through which a 167 network device can be managed. Configuration data, state 168 information, and system notifications can be retrieved. New 169 configuration data can be uploaded and manipulated. The protocol 170 allows the device to expose a full, formal, application programming 171 interface (API). Applications can use this straight-forward API to 172 send and receive full and partial configuration data sets. 174 NETCONF uses a remote procedure call (RPC) paradigm to define a 175 formal API for the network device. A client encodes an RPC in XML 176 [1] and sends it to a server using secure, connection-oriented 177 session. The server responds with a reply encoded in XML. The 178 contents of both the request and the response are fully described in 179 XML DTDs or XML schemas, or both, allowing both parties to recognize 180 the syntax constraints imposed on the exchange. 182 A key aspect of NETCONF is an attempt to allow the functionality of 183 the API to closely mirror the native functionality of the device. 184 This reduces implementation costs and allows timely access to new 185 features. In addition, applications can access both the syntactic 186 and semantic content of the device's native user interface. 188 NETCONF allows a client to discover the set of protocol extensions 189 supported by the server. These "capabilities" permit the client to 190 adjust its behavior to take advantage of the features exposed by the 191 device. The capability definitions can be easily extended in a 192 noncentralized manner. Standard and vendor-specific capabilities can 193 be defined with semantic and syntactic rigor. 195 The NETCONF protocol is a building block in a system of automated 196 configuration. XML is the lingua franca of interchange, providing a 197 flexible but fully specified encoding mechanism for hierarchical 198 content. NETCONF can be used in concert with XML-based 199 transformation technologies such as XSLT to provide a system for 200 automated generation of full and partial configurations. The system 201 can query one or more databases for data about networking topologies, 202 links, policies, customers, and services. This data can be 203 transformed using one or more XSLT [7] scripts from a 204 vendor-independent data schema into a form that is specific to the 205 vendor, product, operating system, and software release. The 206 resulting data can be passed to the device using the NETCONF 207 protocol. 209 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 210 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 211 document are to be interpreted as described in RFC 2119 [2]. 213 1.1 Protocol Overview 215 NETCONF uses a simple RPC-based mechanism to facilitate communication 216 between a client and a server. The client is a script or application 217 typically running as part of a network manager. The server is a 218 network device. The terms "device" and "server" are used 219 interchangeably in this document, as are "client" and "application". 221 NETCONF can be conceptually partitioned into four layers: 223 Layer Example 224 +-------------+ +-----------------------------+ 225 | Content | | Configuration data | 226 +-------------+ +-----------------------------+ 227 | | 228 +-------------+ +-----------------------------+ 229 | Operations | | , | 230 +-------------+ +-----------------------------+ 231 | | 232 +-------------+ +-----------------------------+ 233 | RPC | | , | 234 +-------------+ +-----------------------------+ 235 | | 236 +-------------+ +-----------------------------+ 237 | Transport | | BEEP, SSH, SSL, console | 238 +-------------+ +-----------------------------+ 240 1. The transport layer provides a communication path between the 241 client and server. NETCONF can be layered over any transport 242 that provides a set of basic requirements. Section 2 discusses 243 these requirements. 245 2. The RPC layer provides a simple, transport-independent framing 246 mechanism for encoding RPCs. Section 3 documents this protocol. 248 3. The operations layer defines a set of base operations invoked as 249 RPC methods with XML-encoded parameters. Section 5 details the 250 list of base operations. 252 4. The content layer is outside the scope of this document. Given 253 the current proprietary nature of the configuration data being 254 manipulated, the specification of this content depends on the 255 device vendor. It is expected that a separate effort to specify 256 a standard data definition language and standard content will be 257 undertaken. 259 1.1.1 Capabilities 261 An NETCONF capability is a set of functionality that supplements the 262 base NETCONF specification. The capability is identified by a 263 uniform resource identifier (URI). These URIs should follow the 264 guidelines as described in Section 6. 266 Capabilities augment the base operations of the device, describing 267 both additional operations and the content allowed inside operations. 268 The client can discover the server's capabilities and use any 269 additional operations, parameters, and content defined by those 270 capabilities. 272 The capability definition may name one or more dependent 273 capabilities. These capabilities must be implemented before the 274 first capability can function properly. To support a capability, the 275 server MUST support any capabilities upon which it depends. 277 Section 6 defines the capabilities exchange that allows the client to 278 discover the server's capabilities. Section 6 also lists the set of 279 capabilities defined in this document. 281 Additional capabilities can be defined at any time in external 282 documents, allowing the set of capabilities to expand over time. 283 Standards bodies may define standardized capabilities and vendors may 284 define proprietary ones. The URI MUST sufficiently distinguish the 285 naming authority to avoid naming collisions. 287 1.2 Separation of Configuration and State Data 289 The information that can be retrieved from a running system is 290 separated into two classes, configuration data and state data. 291 Configuration data is the set of writable data that is required to 292 transform a system from its initial default state into its current 293 state. State data is the additional data on a system that is not 294 configuration data such as read-only status information and collected 295 statistics. When a device is performing configuration operations a 296 number of problems would arise if state data were included: 298 o Comparisons of configuration files would be dominated by 299 irrelevant entries such as different statistics. 301 o A command to load the file would contain nonsensical commands such 302 as commands to write read-only data. 304 o The configuration file would be too large. 306 To account for these issues, the NETCONF protocol recognizes the 307 difference between configuration data and state data and provides 308 commands that operate on each independently. For example, the 309 command retrieves configuration data only while the 310 command retrieves state data. 312 Note that the NETCONF protocol is concerned only with information 313 required to get the system software into its desired running state. 314 Other important persistent data such as user files and databases are 315 not treated as configuration data by the NETCONF protocol. 316 Similarly, the collection of configuration files stored on a system 317 (for example, the configuration files themselves) is not itself 318 included in configuration data. 320 If a local database of user authentication data is stored on the 321 device, whether it is included in configuration data is an 322 implementation dependent matter. 324 1.3 Executive Commands 326 The NETCONF protocol provides for executive commands to perform other 327 functions on the system that ease the process of configuring the 328 system. Examples include resetting a line card, issuing ping and 329 traceroute commands, and debugging. 331 1.4 Terminology 333 1.4.1 Configuration Session 335 A configuration session is the logical connection between a network 336 administrator or network configuration application and a network 337 device. A device MUST support at least one concurrent session, and 338 MAY support more than one. Global configuration attributes can be 339 changed during any session, and the affects are visible in all 340 sessions. Session-specific attributes affect only the session in 341 which they are changed. 343 2. Transport Protocol Requirements 345 NETCONF uses an RPC-based communication paradigm. A client sends a 346 series of zero or more RPC request operations, which cause the server 347 to respond with a corresponding series of RPC replies. 349 The NETCONF protocol can be layered on any transport that provides 350 the required set of functionality. It is not bound to any particular 351 transport protocol, but allows a mapping to define how it can be 352 implemented over any specific protocol. 354 This section details the characteristics that NETCONF requires from 355 the underlying transport protocol. 357 2.1 Connection-oriented operation 359 NETCONF is connection-oriented, requiring a persistent connection 360 between peers. This connection must provide reliable, sequenced data 361 delivery. 363 NETCONF connections are long-lived, persisting between protocol 364 operations. This allows the client to make changes to the state of 365 the connection that will persist for the lifetime of the connection. 366 For example, authentication information specified for a connection 367 remains in effect until the connection is closed. 369 In addition, resources requested from the server for a particular 370 connection MUST be automatically released when the connection closes, 371 making failure recovery simpler and more robust. For example, when a 372 lock is acquired by a peer, the lock persists until either explicitly 373 released or the server is informed that the connection has been 374 terminated. If a connection is terminated while the client holds a 375 lock, the server can perform any appropriate recovery. 377 2.2 Security and Privacy 379 NETCONF connections must provide security and privacy. NETCONF 380 depends on the underlying protocol for this capability. An NETCONF 381 peer assumes that an appropriate level of security and privacy are 382 provided independent of this document. For example, connections may 383 be encrypted in TLS [4] (or SSH [11]), depending on the underlying 384 protocol. 386 2.3 Authentication 388 NETCONF connections must be authenticated. The underlying protocol 389 is responsible for authentication. The peer assumes that the 390 connection's authentication information has been validated by the 391 underlying protocol using sufficiently trustworthy mechanisms and 392 that the peer's entity can be trusted. 394 One goal of NETCONF is to provide a programmatic interface to the 395 device that closely follows the functionality of the device's native 396 interface. Therefore, it is expected that the underlying protocol 397 uses existing authentication mechanisms defined by the device. For 398 example, a device that supports RADIUS [5] should use RADIUS to 399 authenticate NETCONF sessions. 401 The authentication process should result in an entity whose 402 permissions and capabilities are known to the device. These 403 permissions must be enforced during the NETCONF session. For 404 example, if the native user interface restricts users from changing 405 the network interface configuration, the user should not be able to 406 change this configuration data using NETCONF. 408 2.4 Channels 410 NETCONF requires two distinct communication channels and an optional 411 third channel. 413 One channel, called the "management channel", carries information for 414 managing the NETCONF session. 416 A second channel, called the "operation channel", carries a series of 417 RPCs that constitute the real content of the NETCONF session. 419 A third optional channel, called the "notification channel", carries 420 asynchronous notifications. This channel is established only if both 421 parties request it during the initial capabilities exchange. (See 422 Section 6 for more information.) 424 2.4.1 Management Channel 426 The NETCONF session is considered to start when the management 427 channel is opened and ends when this channel is closed. If the 428 operation channel is open when the management channel is closed, it 429 should be closed immediately. Only one management channel can exist 430 within a particular session, although multiple sessions can be opened 431 simultaneously. 433 The management channel serves three main purposes: 435 o Advertise the capabilities supported by each peer. 437 o Manage outstanding RPCs on operation channels (that is, aborting 438 them). 440 o Send progress reports. 442 2.4.1.1 Managing Operation Channel 444 Creation of the operation channel is transport-specific. 446 2.4.1.2 Managing Outstanding RPCs 448 XML data streams by their nature prohibit unrelated data from being 449 intermingled with normal content. This implies that an operation 450 must be managed by an external data path to avoid intermixing the 451 true content data with the management data. This is the origin of 452 the requirement for multiple channels. 454 2.4.2 Operation Channel 456 The operation channel is used to perform NETCONF protocol operations 457 using the and tags. The RPC model is discussed in 458 Section 3. 460 Most of the NETCONF operations are performed as RPCs over the 461 operation channel. 463 2.4.3 Notification Channel 465 The NETCONF protocol allows for different notification profiles. A 466 specific profile must be supported by both peers for the notification 467 mechanism defined in that profile to be used. This document 468 specifies a mapping to the Reliable Delivery for Syslog messages. 470 Notifications are discussed in Section 6 and RFC 3195 [6]. 472 3. RPC Model 474 The NETCONF protocol uses an RPC-based communication model. NETCONF 475 peers use and elements to provide 476 transport-independent framing of protocol requests and responses. 478 3.1 Namespace 480 The , , and elements are defined in 481 the following namespace: 483 http://ietf.org/xmlconf/1.0/base 485 3.2 Element 487 The element is used in both the management and operation 488 channels. 490 The element has a mandatory attribute "message-id", which is an 491 arbitrary string chosen by the sender of the RPC that will commonly 492 encode a monotonically increasing integer. The receiver of the RPC 493 does not decode or interpret this string but simply saves it to use 494 as a "message-id" attribute in any resulting , 495 or messages. For example: 497 498 499 ... 500 501 503 The name and parameters of an RPC are encoded as the contents of the 504 element. The name of the RPC is an element directly inside the 505 element, and any parameters are encoded inside this element. 507 The following example invokes a method called "my-own-method" which 508 has two parameters, "my-first-parameter", with a value of "14", and 509 "another-parameter", with a value of "fred": 511 512 513 14 514 fred 515 516 518 The following example invokes a "rock-the-house" method with a 519 "zip-code" parameter of "27606-0100": 521 522 523 27606-0100 524 525 527 The following example invokes the "rock-the-world" method with no 528 parameters: 530 531 532 534 3.3 Element 536 The message is sent on the operations channel in response 537 to a operation. 539 The element has a mandatory attribute "message-id", which 540 is equal to the "message-id" attribute of the for which this is 541 a response. 543 The response name and response data are encoded as the contents of 544 the element. The name of the reply is an element 545 directly inside the element, and any data is encoded 546 inside this element. 548 For example: 550 551 552 ... 553 554 556 3.4 Element 558 The element is sent on the management channel by the 559 sender of an who desires to terminate an operation before it 560 completes. The element includes a mandatory attribute 561 "message-id", which is equal to the "message-id" attribute of the 562 to be terminated. 564 The operation is encoded as an element with no 565 subelements or data. For example: 567 569 An element is sent immediately on the management 570 channel. If the indicated is in progress on the 571 operations channel, it shall be terminated cleanly by closing all 572 open elements. An element (see Section 3.6) should be 573 added to the indicating the operation being aborted. If 574 the has not yet begun, it should be sent containing an 575 element. If multiple requests are pending, the 576 and messages must be sent in the proper 577 order. 579 If no pending operation matches the "message-id" attribute, then the 580 abort operation completes without error. The message can 581 be generated only for requests that contain a "message-id" 582 attribute. If multiple requests with the same "message-id" 583 exist, then only the request that was received first by the peer is 584 aborted. 586 3.5 Element 588 The message is sent on the management channel in 589 response to an operation. 591 The message has a mandatory attribute "message-id", 592 which is equal to the "message-id" attribute of the for 593 which this is a response. 595 The operation is encoded as an empty element. For 596 example: 598 600 3.6 Element 602 The element is sent in messages if an error 603 occurs during the processing of an request. 605 The element includes the following information: 607 o tag: String identifying the error condition. 609 o error-code: Integer identifying the error condition. 611 o severity: String identifying the error severity, as determined by 612 the device. 614 o edit-path: Configuration data that provides the context for the 615 command that caused the error. This can be the empty string if 616 the command causing the error is located at the top level of the 617 command hierarchy. 619 o statement: Configuration or command that caused the error. 621 o message: String describing the error condition. 623 o action: Action taken by the device in response to this error. 625 [ed: A list of standard error codes is TBD. Both protocol error and 626 application error codes will be supported by .] 628 629 EXAMPLE_MTU_RANGE 630 128 631 error 632 mtu 21050; 633 MTU 21050 on Ethernet/1 is outside range 256..9192 634 636 3.7 Element 638 The element is sent in messages if no error occurred 639 during the processing of an request. For example: 641 642 643 645 3.8 Element 647 Some operations might take a long time to process before an 648 can be generated or might generate an that 649 takes a long time to transmit. If the recipient of an 650 determines that the will not be generated and transmitted 651 in less than N seconds, it can send a progress report with the 652 message. The number of seconds, N, is implementation 653 dependent. 655 The element is sent on the management channel. It has 656 a mandatory attribute "message-id", which is equal to the 657 "message-id" attribute of the associated on which progress is 658 being reported. 660 The element contains one or more of the optional 661 elements , , and . 663 The element contains an estimate of the percentage of 664 the operation that is complete in terms of real time (i.e., wall 665 clock time). For example: 667 668 45 669 671 The element contains an absolute quantity indicating an 672 amount of work completed. For example: 674 675 45KB 676 678 The element contains a text message indicating progress on 679 the associated . For example: 681 682 Connecting... 683 684 685 Connected. 686 688 Multiple messages can be sent for a particular . 690 3.9 Pipelining 692 The operations channel is processed serially by the managed device. 693 Additional requests may be sent before previous ones have been 694 completed, but they are added to the queue for that channel. On any 695 given operations channel, the managed device may send responses only 696 in the order the requests were received. 698 Messages may be received asynchronously on the notification channel. 700 4. Configuration Model 702 NETCONF provides an initial set of operations and a number of 703 capabilities that can be used to extend the base. NETCONF peers 704 exchange device capabilities when the session is initiated as 705 described in Section 6.1. 707 4.1 Configuration Datastores 709 NETCONF defines the existence of one or more configuration datastores 710 and allows configuration operations on them. A configuration 711 datastore is defined as the complete set of configuration data that 712 is required to get a device from its initial default state into a 713 desired operational state. The configuration datastore does not 714 include state data or executive commands. 716 The following configuration datastores are present in the base model. 717 Capabilities may define additional configuration datastores, which 718 then are available only on devices that advertise the capabilities. 720 o Running: The complete configuration currently active on the 721 network device. Only one configuration datastore of this type 722 exists on the device, and it is always present. NETCONF protocol 723 operations refer to this datastore using the element. 725 5. Protocol Operations 727 The NETCONF protocol provides a small set of low-level operations to 728 manage device configurations and retrieve device state information. 729 The base protocol provides operations to retrieve, configure, copy, 730 and delete configuration datastores. Additional operations are 731 provided, based on the capabilities advertised by the device. 733 The base protocol includes the following protocol operations: 735 o get-config 737 o edit-config 739 o copy-config 741 o delete-config 743 o get-state 745 o kill-session 747 A protocol operation may fail for various reasons, including 748 "operation not supported". An initiator should not assume that any 749 operation will always succeed. The return values in any RPC reply 750 should be checked for error responses. 752 The syntax and XML encoding of the protocol operations are formally 753 defined in the XML schema in Section 8. The following sections 754 describe the semantics of each protocol operation. 756 5.1 758 Description: 760 Retrieve all or part of a specified configuration. 762 Parameters: 764 source: @config-name 766 Name of the configuration datastore being queried, such as 767 or . 769 config: @element-subtree 771 Portions of the configuration command subtree to retrieve. 772 The namespace of this configuration should be specified as 773 an attribute of this parameter. If this parameter is empty, 774 the entire configuration is returned. If the format 775 parameter is equal to "text", the contents of this parameter 776 are proprietary. 778 format: (xml | text) 780 Format of the return text, either "xml" or "text". If this 781 parameter contains the value "xml", the contents of the 782 "config" parameter are expected to conform to the XML 783 Namespace specified in that parameter. If the value is 784 "text", the contents of the "config" parameter are 785 proprietary. 787 Positive Response: 789 If the device can satisfy the request, the server sends an 790 element containing a element with the 791 results of the query. 793 Negative Response: 795 An element is included in the if the 796 request cannot be completed for any reason. 798 Example: 800 801 802 803 804 805 806 807 808 xml 809 810 812 813 814 815 816 root 817 superuser 818 Charlie Root 819 820 821 fred 822 admin 823 Fred Flintstone 824 825 826 barney 827 admin 828 Barney Rubble 829 830 831 832 834 The following example shows how additional nesting within the 835 parameter can be used to filter more of the output in the 836 response: 838 839 840 841 842 843 844 845 846 fred 847 848 849 850 xml 851 852 854 855 856 857 858 fred 859 admin 860 Fred Flintstone 861 862 863 864 866 5.2 868 Description: 870 Load all or part of a specified configuration to the specified 871 target configuration. This operation allows the new 872 configuration to be expressed in several ways, such as using a 873 local file, a remote file, or inline. If the target 874 configuration does not exist, it is created. 876 The device analyzes the source and target configurations and 877 performs the requested changes. The target configuration is 878 not simply replaced, as with the command. 880 Attributes: 882 operation: (merge | replace | delete) [default: merge] 883 Elements in the subtree may contain an operation 884 attribute. The attribute identifies the point in the 885 configuration to perform the operation. 887 In the interest of simplicity, all operation attributes 888 appearing within the subtree MUST have the same value. 890 If the operation attribute is not specified, the configuration 891 is merged into the configuration datastore. 893 The operation attribute has one of the following values: 895 merge: The configuration data identified by the element 896 containing this attribute is merged with the configuration 897 at the corresponding level in the configuration datastore 898 identified by the target parameter. 900 replace: The configuration data identified by the element 901 containing this attribute replaces any related configuration 902 in the configuration datastore identified by the target 903 parameter. Unlike a operation, which replaces 904 the entire target configuration, only the configuration 905 actually present in the config parameter is affected. 907 delete: The configuration data identified by the element 908 containing this attribute is deleted in the configuration 909 datastore identified by the target parameter. 911 [ed. The operation attribute needs to be added to the XML 912 schema in Section 8.] 914 Parameters: 916 target: @config-name 918 Configuration datastore being edited, such as . 920 test-option: (test-then-set | set) [default: set] 922 test-then-set: Perform a validation test before attempting 923 to set; skip set if any errors. 925 set: Perform a set without a validation test first. 927 The test-option element may be specified only if the device 928 advertises the #validate capability (Section 6.4). 930 error-option: (stop-on-error | ignore-error) [default: 931 stop-on-error] 933 stop-on-error: Abort the rpc request on first error. 935 ignore-error: Continue to process configuration data on 936 error; error is recorded and negative response is generated 937 if any errors occur. 939 config: @element-tree 941 Portion of the configuration subtree to set. The namespace 942 of this configuration should be specified as an attribute of 943 this parameter. 945 Positive Response: 947 If the device was able to satisfy the request, an 948 is sent containing an element. 950 Negative Response: 952 An response is sent if the request cannot be 953 completed for any reason. 955 Example: Set the MTU to 1500 on an interface named "Ethernet0/0" in 956 the running configuration: 958 959 960 961 962 963 964 965 Ethernet0/0 966 1500 967 968 969 970 972 973 974 976 Add an interface named "Ethernet0/0" to the running configuration, 977 replacing any previous interface with that name: 979 980 981 982 983 984 986 987 Ethernet0/0 988 1500 989
990 1.2.3.4 991 255.0.0.0 992
993 994 995 996 998 999 1000 1002 Delete the interface named "Ethernet0/0" from the running 1003 configuration: 1005 1006 1007 1008 1009 1010 1012 1013 Ethernet0/0 1014 1015 1016 1017 1019 1020 1021 1023 Delete interface 192.168.0.1 from an OSPF area (other interfaces 1024 configured in the same area are unaffected): 1026 1027 1028 1029 1030 1031 1033 1034 1035 1036 0.0.0.0 1037 1038 1039 192.168.0.1 1040 1041 1042 1043 1044 1045 1046 1047 1049 1050 1051 1053 5.3 1055 Description: 1057 Create or replace an entire configuration file with the 1058 contents of another complete configuration file. If the target 1059 file exists, it is overwritten; otherwise, a new file is 1060 created. 1062 A device may choose not to support the configuration 1063 datastore as the parameter of a 1064 operation. A device may choose not to support remote to remote 1065 copy operations. The source and target parameters cannot 1066 identify the same file. 1068 The device may choose not to support format conversions with 1069 this operation. The running and startup configurations are 1070 considered to be format neutral, but all other configuration 1071 files are created in a specific format (text or XML). A copy 1072 operation on any of these format-specific files may fail if the 1073 format parameter specifies a value different than the source 1074 file format. It is suggested that the format parameter be 1075 omitted in this type of operation, to select the source file 1076 format. 1078 Parameters: 1080 source: @config-name | config 1082 Name of the configuration datastore to use as the source of 1083 the copy operation or the element containing the 1084 configuration subtree to copy. 1086 target: @config-name 1088 Name of the configuration datastore to use as the 1089 destination of the copy operation. 1091 format: (xml | text) [Default: xml] 1093 Format of the configuration file, either "xml" or "text". 1094 The format of the source and target configurations must 1095 match. Configuration datastores (such as ) match 1096 either format. 1098 Positive Response: 1100 If the device was able to satisfy the request, an 1101 is sent that includes an element. 1103 Negative Response: 1105 An element is included within the if 1106 the request cannot be completed for any reason. 1108 Example: 1110 1111 1112 1113 1114 1115 1116 ftp://example.com/configs/testbed-dec10.txt 1117 1118 text 1119 1120 1122 1123 1124 1126 5.4 1128 Description: 1130 Delete a configuration datastore. The configuration 1131 file cannot be deleted. 1133 Parameters: 1135 target: @config-name 1137 Name of the configuration datastore to delete. 1139 Positive Response: 1141 If the device was able to satisfy the request, an 1142 is sent that includes an element. 1144 Negative Response: 1146 An element is included within the if 1147 the request cannot be completed for any reason. 1149 Example: 1151 1152 1153 1154 1155 1156 1157 1159 1160 1161 1163 5.5 1165 Description: 1167 Retrieve device state information. Section 9 describes the XML 1168 schema for NETCONF state data. 1170 Parameters: 1172 state: (@element-subtree | text) 1174 If the parameter is equal to "xml", this parameter 1175 specifies the portion of the system state subtree to 1176 retrieve. The namespace of this configuration should be 1177 specified as an attribute of this parameter. If the 1178 parameter is equal to "text", the contents of this 1179 parameter are proprietary. If this parameter is empty, all 1180 the device state information are returned. 1182 format: (xml | text) 1184 Format of the parameter and the return text, either 1185 "xml" or "text". 1187 Positive Response: 1189 If the device was able to satisfy the request, an 1190 is sent. The section contains the appropriate subset. 1192 Negative Response: 1194 An element is included in the if the 1195 request cannot be completed for any reason. 1197 Example: 1199 1200 1201 1202 1203 1204 1205 1206 xml 1207 1208 1210 1211 1212 1213 1214 9456823 1215 1228484566 1216 4326 1217 4821050 1218 634712154 1219 2096 1220 1221 1222 1223 1225 5.6 1227 Description: 1229 Force the termination of an NETCONF session. 1231 Parameters: 1233 session-id: (Positive Integer) 1235 Session identifier of the NETCONF session to be terminated. 1236 If this value is equal to the current session ID, a 'Bad 1237 Value' error is sent. 1239 Positive Response: 1241 If the device was able to satisfy the request, an 1242 is sent that includes an element. 1244 Negative Response: 1246 An element is included in the if the 1247 request cannot be completed for any reason. 1249 Example: 1251 1252 1253 4 1254 1255 1257 1258 1259 1261 6. Capabilities 1263 This section defines a set of capabilities that a client or a server 1264 MAY implement. Each peer advertises its capabilities by sending them 1265 during an initial capabilities exchange. Each peer needs to 1266 understand only those capabilities that it might use and must be able 1267 to process and ignore any capability received from the other peer 1268 that it does not require or does not understand. 1270 Additional capabilities can be defined using the template in Appendix 1271 A. Future capability definitions may be published as standards by 1272 standards bodies or published as propriety by vendors. 1274 A capability is identified with a URI, in the form: 1276 http://{naming authority}/{protocol}/{version}/{category}#{name} 1278 Capabilities defined in this document have the following format: 1280 http://ietf.org/xmlconf/1.0/base#{name} 1282 where {name} is the name of the capability. Capabilities are often 1283 referenced in discussions and email using the shorthand #{name}. For 1284 example, the foo capability would have the formal name "http:// 1285 ietf.org/xmlconf/1.0/base#foo" and be called "#foo". The shorthand 1286 form MUST NOT be used inside the protocol. 1288 6.1 Capabilities Exchange 1290 An NETCONF capability is a set of additional functionality 1291 implemented on top of the base NETCONF specification. The capability 1292 is distinguished by a URI. These URIs should follow the guidelines 1293 as described in Section 7.7. 1295 Capabilities are advertised in messages sent on the management 1296 channel when each peer starts operation. When the management channel 1297 is opened, each peer sends a element containing a list of 1298 that peer's capabilities. 1300 In the following example, the peer advertises the base NETCONF 1301 capability, one NETCONF capability defined in the base NETCONF 1302 document, and one vendor-specific capability. 1304 1305 1306 http://ietf.org/xmlconf/1.0/base 1307 http://ietf.org/xmlconf/1.0/base#lock 1308 http:/example.net/router/2.3/core#cool-feature 1309 1310 1312 Each peer sends its element simultaneously as soon as the 1313 connection is open. A peer MUST NOT wait to receive the capability 1314 set from the other side before sending its own set. 1316 6.2 Writable-Running Capability 1318 6.2.1 Description 1320 The #writable-running capability indicates that the device supports 1321 writes directly to the configuration datastore. In other 1322 words, the device supports edit-config and copy-config operations 1323 where the configuration is the target. 1325 6.2.2 Dependencies 1327 None. 1329 6.2.3 Capability and Namespace 1331 The #writable-running capability is identified by the following 1332 capability string: 1334 http://ietf.org/xmlconf/1.0/base#writable-running 1336 The #writable-running capability uses the base NETCONF namespace URI. 1338 6.2.4 New Operations 1340 None. 1342 6.2.5 Modifications to Existing Operations 1344 6.2.5.1 1346 The #writable-running capability modifies the operation 1347 to accept the element as a . 1349 6.2.5.2 1351 The #writable-running capability modifies the operation 1352 to accept the element as a . 1354 6.3 Candidate Configuration Capability 1356 6.3.1 Description 1358 The candidate configuration capability, #candidate, indicates that 1359 the device supports a candidate configuration datastore, which is 1360 used to hold configuration data that can manipulated without 1361 impacting the device's current configuration. The candidate 1362 configuration is a full configuration data set that serves as a work 1363 place for creating a manipulating configuration data. Additions, 1364 deletions, and changes may be made to this data to construct the 1365 desired configuration data. A operation may be performed at 1366 any time that causes the device's running configuration to be set to 1367 the value of the candidate configuration. 1369 The candidate configuration can be used as a source or target of any 1370 operation with a or parameter. The 1371 element is used to indicate the candidate configuration: 1373 1374 1375 1376 1377 1378 1379 1381 The candidate configuration may be shared among multiple sessions. 1382 Unless a client has specific information that the candidate 1383 configuration is not shared (for example, through another 1384 capability), it must assume that other sessions may be able to modify 1385 the candidate configuration at the same time. It is therefore 1386 prudent for a client to lock the candidate configuration before 1387 modifying it. 1389 The client can discard any changes since the last operation 1390 by executing the operation. The candidate 1391 configuration's content then reverts to the current committed 1392 configuration. 1394 6.3.2 Dependencies 1396 The #candidate capability requires that the #lock capability be 1397 implemented. Manipulation of a candidate configuration without a 1398 locking mechanism is not advised. 1400 6.3.3 Capability and Namespace 1402 The #candidate capability is identified by the following capability 1403 string: 1405 http://ietf.org/xmlconf/1.0/base#candidate 1407 The #candidate capability uses the base NETCONF namespace URI. 1409 6.3.4 New Operations 1411 6.3.4.1 1413 Description: 1415 When a candidate configuration's content is complete, the 1416 configuration data can be committed, publishing the data set to 1417 the rest of the device and requesting the device to conform to 1418 the behavior described in the new configuration. 1420 To commit the candidate configuration as the device's new 1421 current configuration, use the operation. 1423 The operation instructs the device to implement the 1424 configuration data contained in the candidate configuration. 1426 If the system does not have the #candidate capability, the 1427 operation is not available. 1429 Parameters: 1431 confirmed: 1433 The element indicates that the 1434 operation MUST be reverted if a confirming commit is not 1435 issued within ten (10) minutes. The timeout period can be 1436 adjusted with the element. 1438 confirmed-timeout: Timeout period for confirmed commit, in 1439 minutes. 1441 Positive Response: 1443 If the device was able to satisfy the request, an 1444 is sent that contains an element. 1446 Negative Response: 1448 An element is included in the if the 1449 request cannot be completed for any reason. 1451 Example: 1453 1454 1455 1457 1458 1459 1461 1462 1463 1464 20 1465 1466 1468 1469 1470 1472 6.3.4.2 1474 If the client decides that the candidate configuration should not be 1475 committed, the operation can be used to revert the 1476 candidate configuration to the current committed configuration. 1478 1479 1480 1482 This operation discards any uncommitted changes. 1484 6.3.5 Modifications to Existing Operations 1486 6.3.5.1 and 1488 The candidate configuration can be locked using the operation 1489 with the element at the parameter: 1491 1492 1493 1494 1495 1496 1497 1499 Devices implementing the #candidate capability WILL NOT allow a 1500 configuration lock to be acquired when there are outstanding changes 1501 to the candidate configuration. An error WILL be returned and the 1502 status of the lock will remain unchanged. 1504 When a client fails with outstanding changes to the candidate 1505 configuration, recovery can be difficult. To facilitate easy 1506 recovery, the #candidate capability adds a element 1507 to the operation. If this element contains the value 1508 "automatic", any outstanding changes are discarded when the lock is 1509 released, whether explicitly with the operation or 1510 implicitly from session failure. 1512 1513 1514 1515 1516 1517 automatic 1518 1519 1521 6.3.5.2 and 1523 The candidate configuration is the default target for the 1524 and operations. It may be explicitly 1525 named using the element: 1527 1528 1529 1530 1531 1532 1533 1535 6.4 Validate Capability 1537 6.4.1 Description 1539 Validation consists of checking a candidate configuration for 1540 syntactical and semantic errors before applying the configuration to 1541 the device. 1543 If this capability is advertised, the device supports the 1544 protocol operation and checks at least for syntax errors. In 1545 addition, this capability supports the validate parameter to the 1546 operation and, when it is provided, checks at least for 1547 syntax errors. 1549 6.4.2 Dependencies 1551 None. 1553 6.4.3 Capability and Namespace 1555 The #validate capability is identified by the following capability 1556 string: 1558 http://ietf.org/xmlconf/1.0/base#validate 1560 The #validate capability uses the base NETCONF namespace URI. 1562 6.4.4 New Operations 1564 6.4.4.1 1566 Description: 1568 This protocol operation validates the contents of the specified 1569 configuration. 1571 Parameters: 1573 source: @config-name 1575 Name of the configuration datastore being validated, such as 1576 . 1578 Positive Response: 1580 If the device was able to satisfy the request, an 1581 is sent that contains an element. 1583 Negative Response: 1585 An element is included in the if the 1586 request cannot be completed for any reason. 1588 A validate operation can fail for any of the following reasons: 1590 + Syntax errors 1592 + Missing parameters 1594 + References to undefined configuration data 1596 Example: 1598 1599 1600 1601 1602 1604 1605 1606 1608 6.5 Distinct Startup Capability 1610 6.5.1 Description 1612 The device supports separate running and startup configuration 1613 datastores. Operations which affect the running configuration will 1614 not be automatically copied to the startup configuration. An 1615 explicit operation from the to the 1616 must be invoked to update the startup configuration to the current 1617 contents of the running configuration. NETCONF protocol operations 1618 refer to the startup datastore using the element. 1620 6.5.2 Dependencies 1622 None. 1624 6.5.3 Capability and Namespace 1626 The #startup capability is identified by the following capability 1627 string: 1629 http://ietf.org/xmlconf/1.0/base#startup 1631 The #startup capability uses the base NETCONF namespace URI. 1633 6.5.4 New Operations 1635 None. 1637 6.5.5 Modifications to Existing Operations 1639 6.5.5.1 1641 To save the startup configuration, use the copy-config command to 1642 copy the configuration datastore to the 1643 configuration datastore. 1645 1646 1647 1648 1649 1650 1651 1652 1653 text 1654 1655 1657 6.6 Lock Capability 1659 6.6.1 Description 1661 The #lock capability allows the client to lock the configuration 1662 system of a device. Such locks are intended to be short-lived and 1663 allow a client to make a change without fear of interaction with 1664 other NETCONF clients, non-NETCONF clients (SNMP and Expect scripts) 1665 and human users. 1667 An attempt to lock the configuration MUST fail if an existing session 1668 currently holds the lock. 1670 When the lock is acquired, the server MUST prevent any changes to the 1671 locked resource other than those requested by this session. SNMP and 1672 CLI requests to modify the resource MUST fail with an appropriate 1673 error. 1675 The duration of the lock is defined as beginning when the lock is 1676 acquired and lasting until either the lock is released or the NETCONF 1677 session closes. The session closure may be explicitly performed by 1678 the client, or implicitly performed by the server based on criteria 1679 such as lack of network connectivity, failure of the underlying 1680 transport, or simple inactivity timeout. This criteria is dependent 1681 on the vendor's implementation and the underlying transport. 1683 The lock operation takes an optional parameter, target. If the 1684 target parameter is specified, it names the configuration that will 1685 be locked. If the target parameter is not specified, then all 1686 configurations will be locked. When a lock is active, 1687 and operations will be disallowed on the locked 1688 configuration(s) by any other session. Additionally, the system will 1689 ensure that these locked configuration resources will not be modified 1690 by other non-NETCONF management operations such as SNMP and CLI. The 1691 command (at the RPC layer) can be used to force the 1692 release of a lock. 1694 6.6.2 Dependencies 1696 None. 1698 6.6.3 Capability and Namespace 1700 The #lock capability is identified by the following capability 1701 string: 1703 http://ietf.org/xmlconf/1.0/base#lock 1705 The #lock capability uses the base NETCONF namespace URI. 1707 6.6.4 New Operations 1709 6.6.4.1 1711 Description: 1713 A configuration source can be locked by using the 1714 operation. A lock will not be granted if any of the following 1715 conditions are true: 1717 + a lock is already held by another session 1719 + the target configuration has already been modified and these 1720 changes have not been committed 1722 + lock capability not supported 1724 The server MUST respond with either an element or an 1725 . 1727 A lock will be released by the system if the session holding 1728 the lock is terminated for any reason. 1730 Parameters: 1732 target: @config-name [Optional] 1734 Name of the configuration datastore to lock. If this 1735 parameter is not present, than all configuration datastores 1736 will be locked. 1738 Positive Response: 1740 If the device was able to satisfy the request, an 1741 is sent that contains an element. 1743 Negative Response: 1745 An element is included in the if the 1746 request cannot be completed for any reason. This error 1747 response will include the session number of the lock owner (if 1748 failure due to lock already held). 1750 Example: 1752 1753 1754 1755 1756 1757 1758 1760 1761 1762 1764 6.6.4.2 1766 Description: 1768 The unlock operation is used to release a configuration lock, 1769 previously obtained with the operation. 1771 An unlock operation will not succeed if any of the following 1772 conditions are true: 1774 + the specified lock is not currently active 1776 + the session issuing the operation is not the same 1777 session that obtained the lock 1779 The server MUST respond with either an element or an 1780 . 1782 Parameters: 1784 target: @config-name [Optional] 1786 Name of the configuration datastore to unlock. If this 1787 parameter is not present, than all configuration datastores 1788 will be unlocked. 1790 An NETCONF client is not permitted to unlock a configuration 1791 datastore that it did not lock. 1793 Positive Response: 1795 If the device was able to satisfy the request, an 1796 is sent that contains an element. 1798 Negative Response: 1800 An element is included in the if the 1801 request cannot be completed for any reason. 1803 Example: 1805 1806 1807 1808 1809 1810 1811 1813 1814 1815 1817 6.7 Notifications Capability 1818 6.7.1 Description 1820 The #notifications capability indicates that the server supports the 1821 notification channel. This channel provides a mechanism for sending 1822 asynchronous notifications within the NETCONF session. This channel 1823 can be used for events and system logging. 1825 6.7.2 Dependencies 1827 None. 1829 6.7.3 Capability and Namespace 1831 The #notifications capability is identified by the following 1832 capability string: 1834 http://ietf.org/xmlconf/1.0/base#notifications 1836 The #notifications capability uses the base NETCONF namespace URI. 1838 6.7.4 New Operations 1840 6.7.4.1 1842 Description: 1844 Use the operation to request the 1845 notification channel with a specific set of parameters. If 1846 successful, the underlying protocol will open the notification 1847 channel with the appropriate parameters. 1849 Parameters: 1851 format: format 1853 Indicates the format of the notification channel. The only 1854 legal value is "rfc3195". 1856 matching: match-expression [Optional] 1858 An optional parameter that limits notifications sent on the 1859 channel to those matching the match-expression. 1861 Positive Response: 1863 If the device was able to satisfy the request, an 1864 is sent that contains an element. 1866 Negative Response: 1868 An element is included in the if the 1869 request cannot be completed for any reason. 1871 Example: 1873 1874 1875 rfc3195 1876 match-expression 1877 1878 1880 1881 1882 1884 6.7.4.2 1886 Description: 1888 Use the operation to close the 1889 notification channel. If successful, the underlying protocol 1890 will close the notification channel. 1892 Positive Response: 1894 If the device was able to satisfy the request, an 1895 is sent that contains an element. 1897 Negative Response: 1899 An element is included in the if the 1900 request cannot be completed for any reason. 1902 Example: 1904 1905 1906 1908 1909 1910 1912 6.8 URL Capability 1914 6.8.1 Description 1916 The NETCONF peer has the ability to accept the element in 1917 and parameters. The capability is further 1918 identified by URL arguments indicating the protocols supported. 1920 6.8.2 Dependencies 1922 None. 1924 6.8.3 Capability and Namespace 1926 The #url capability is identified by the following capability string: 1928 http://ietf.org/xmlconf/1.0/base#url?protocol={protocol-name,...} 1930 The #url capability uses the base NETCONF namespace URI. 1932 The #url capability URI MUST contain a "protocol" argument assigned a 1933 comma-separated list of protocol names indicating which protocols the 1934 NETCONF peer supports. For example: 1936 http://ietf.org/xmlconf/1.0/base#url?protocol=http,ftp,file 1938 The #url capability uses the base NETCONF namespace URI. 1940 6.8.4 New Operations 1942 None. 1944 6.8.5 Modifications to Existing Operations 1946 6.8.5.1 1948 The #url capability modifies the operation to accept 1949 the element as the parameter. 1951 6.8.5.2 1953 The #url capability modifies the operation to accept 1954 the element as the value of the the and the 1955 parameters. 1957 6.8.5.3 1959 The #url capability modifies the operation to accept 1960 the element as the value of the the parameters. If 1961 this parameter contains a URL, then it should identify a local 1962 configuration file. 1964 6.8.5.4 1966 The #url capability modifies the operation to accept the 1967 element as the value of the the parameter. 1969 7. XML Usage Guidelines for NETCONF 1971 XML serves as an encoding format for NETCONF, allowing complex 1972 hierarchical data to be expressed in a text format that can be read, 1973 saved, and manipulated with both traditional text tools and tools 1974 specific to XML. 1976 To simplify manipulation of NETCONF content, use of XML is restricted 1977 to a simple subset of XML, as described in this section. 1979 7.1 No DTDs 1981 Document type declarations (DTDs) are not permitted to appear in 1982 NETCONF content. 1984 7.2 Avoid Mixed Content 1986 Mixed content is defined as elements that can contain both data and 1987 other elements. Elements in NETCONF can contain either data or 1988 additional elements only. 1990 This greatly simplifies the complexity of parsing XML, especially in 1991 the area of significant whitespace. Whitespace inside data elements 1992 is significant. Whitespace outside data elements is not. 1994 1995 data 1996 data 1997 1999 2000 datadatamaybe some 2001 2003 7.3 No Attributes in the Default Namespace 2005 Do not use attributes in the default namespace. All attributes 2006 should be qualified. 2008 Unqualified attributes belong to the default namespace, and their use 2009 pollutes the default namespace. Restricting them to the current 2010 namespace encourages meaningful definitions that are free of 2011 collisions. 2013 2015 2017 7.4 Use Container Elements for Lists 2019 When encoding lists with multiple instances, use a distinct container 2020 element, preferably the plural form of the instance element. 2022 In this example, the element 'grommet' is contained within the 2023 'grommets' element. 2025 2026 2027 .... 2028 .... 2029 .... 2030 2031 2033 Use of container elements allows simpler manipulation of lists and 2034 list members. 2036 7.5 Elements and Attributes 2038 The choice of elements and attributes has been widely discussed, but 2039 no absolute guidelines exist. When designing encoding rules for 2040 NETCONF content, the following guidelines should be used: 2042 7.5.1 Consider Attributes as Metadata 2044 Attributes should contain metadata about the element, not true data. 2045 By extension, vital information should not be encoded in attributes. 2047 7.5.2 Consider the Lack of Extensibility of Attributes 2049 Attributes are unordered, can appear only once, and can have no 2050 children. Data scenarios which must leave room for future expansion 2051 (in future specifications or future software releases) should avoid 2052 attributes. 2054 7.6 Proper Tag Names 2056 When choosing element names, consider the following guidelines: 2058 o Prefer ASCII (7-bit). 2060 o Prefer lowercase. 2062 o Prefer dashes to underscores. 2064 o Prefer full words. Note that "config" is considered a full word. 2066 These are guidelines only and should be considered secondary to the 2067 need for consistency with existing vocabularies. For example, when 2068 encoding MIB variables names in NETCONF, use the existing names 2069 (ifAddr) instead of shifting to these guidelines (if-address). These 2070 guidelines are valuable when no common vocabulary exists, because 2071 they help to avoid the scenario in which a dozen developers choose a 2072 dozen names that differ in ways that lead to frustrating 2073 inconsistencies, such as ifaddr, if-addr, if-address, 2074 interface-address, intf-addr, iaddr, and iface-addr. 2076 7.7 Namespaces 2078 A namespace URI uniquely identifies the content and meaning of an XML 2079 element. When designing XML namespaces for NETCONF content, the 2080 following guidelines should be used: 2082 o Prefer domain names in URIs. Use the domain name of the 2083 organization that controls the content of the scheme. 2085 o Prefer version numbers in namespaces. Use dates when version 2086 numbers are not appropriate. Versions should be formatted in 2087 strings that are consistent with the software being referenced. 2088 Dates should be formatted as "YYYY-MM-DD". 2090 o Prefer URLish URIs, but do not expect them all to be reachable or 2091 meaningful. While URIs are not URLs and are not required to 2092 reference any resource, using non-URL syntax is needlessly 2093 confusing. For example, the following URI looks like a programmer 2094 mistake: 2096 ietf.org:/rfc/rfc1234.txt 2098 The model namespace looks like: 2100 http://${naming-authority}/${topic}/${version}/${area} 2102 For example: 2104 http://ietf.org/xmlconf/1.0/base-config 2106 In this usage, 'topic' might be the product name, 'version' might be 2107 the software version, and 'area' might be the portion of that 2108 software documented in this particular namespace. 2110 http://example.net/magic-os/84.1.3/bgp 2112 The ${topic} segment might contain a qualifying hierarchy. For 2113 example, if the Puff Router Company has a large set of operating 2114 systems targeted at differing market segments, it may express this 2115 relationship in the ${topic}: 2117 http://example.net/embedded/magic-os/84.1.3/bgp 2119 8. XML Schema for NETCONF RPC and Protocol Operations 2121 2122 2126 2127 2128 2129 2130 2131 2132 2133 2134 2135 2136 2137 2138 2139 2140 2141 2142 2143 2144 2145 2146 2147 2149 2150 2151 2152 2153 2154 2155 2156 2157 2158 2159 2160 2161 2162 2163 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2181 2182 2183 2184 2185 2186 2187 2188 2189 2190 2191 2192 2193 2194 2195 2196 2197 2199 2200 2202 2203 2204 2205 2206 2207 2208 2209 2210 2211 2212 2213 2215 2216 2217 2218 2219 2220 2222 2224 2226 2228 2229 2230 2231 2232 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242 2243 2244 2245 2246 2247 2248 2249 2250 2251 2252 2253 2254 2255 2256 2257 2258 2259 2260 2261 2262 2264 2265 2266 2267 2268 2269 2270 2271 2272 2273 2274 2275 2276 2277 2278 2280 2281 2282 2283 2284 2285 2286 2287 2288 2289 2290 2291 2293 2294 2295 2296 2297 2298 2299 2300 2301 2302 2304 2305 2306 2307 2308 2309 2310 2312 2313 2314 2315 2317 2318 2319 2320 2321 2322 2323 2324 2325 2326 2328 2329 2330 2331 2332 2333 2334 2335 2336 2337 2338 2340 2341 2342 2343 2344 2345 2346 2347 2348 2349 2351 2352 2353 2354 2355 2356 2357 2358 2359 2361 2362 2364 2365 2366 2367 2368 2369 2371 2372 2373 2374 2375 2376 2377 2378 2379 2380 2382 2384 9. XML Schema for NETCONF State Data 2386 2392 2393 2394 Initial schema for NETCONF state information. 2395 2396 2398 2399 2400 2402 2403 2404 2405 List of NETCONF capabilities supported by this device. 2406 2407 2408 2409 2410 2412 2413 2414 2416 2417 2418 2419 List of NETCONF sessions currently active on this device. 2420 2421 2422 2423 2424 2425 2427 2428 2429 2430 2431 2432 2433 List of NETCONF configuration databases supported on this device. 2434 2435 2436 2437 2438 2440 2441 2442 2444 2445 2446 2448 2449 2450 2451 2452 2453 2454 2456 2457 2458 2459 2460 2461 2463 2464 2465 2466 2467 2468 2469 2471 2472 2473 2474 2475 2476 2477 2479 2480 2481 2482 2484 2485 2487 2489 10. Security Considerations 2491 Configuration information is by its very nature sensitive. Its 2492 transmission in the clear and without integrity checking leaves 2493 devices open to classic so-called "person in the middle" attacks. 2494 Configuration information often times contains passwords, user names, 2495 service descriptions, and topological information, all of which are 2496 sensitive. 2498 The protocol, therefore, must minimally support options for both 2499 confidentiality and authentication. 2501 Different environments may well allow different rights prior to and 2502 then after authentication. Thus, an authorization model is not 2503 specified in this document. When an operation is not properly 2504 authorized then a simple "permission denied" is sufficient. Note 2505 that authorization information may be exchanged in the form of 2506 configuration information, which is all the more reason to ensure the 2507 security of the connection. 2509 11. Authors and Acknowledgements 2511 This document was written by: 2513 Andy Bierman, Cisco Systems 2515 Ken Crozier, Cisco Systems 2517 Rob Enns, Juniper Networks 2519 Ted Goddard, Wind River 2521 Eliot Lear, Cisco Systems 2523 David Perkins, Riverstone Networks 2525 Phil Shafer, Juniper Networks 2527 Steve Waldbusser 2529 Margaret Wasserman, Wind River 2531 Normative References 2533 [1] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 2534 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC 2535 REC-xml-20001006, October 2000. 2537 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2538 Levels", BCP 14, RFC 2119, March 1997. 2540 [3] Myers, J., "Simple Authentication and Security Layer (SASL)", 2541 RFC 2222, October 1997. 2543 [4] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 2544 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 2545 1999. 2547 [5] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 2548 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2549 2000. 2551 [6] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, 2552 November 2001. 2554 Informative References 2556 [7] Clark, J., "XSL Transformations (XSLT) Version 1.0", W3C REC 2557 REC-xslt-19991116, November 1999. 2559 [8] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the 2560 Use of Extensible Markup Language (XML) within IETF Protocols", 2561 BCP 70, RFC 3470, January 2003. 2563 [9] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 2001. 2565 [10] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 2566 3080, March 2001. 2568 [11] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH 2569 Protocol Architecture", draft-ietf-secsh-architecture-13 (work 2570 in progress), September 2002. 2572 Author's Address 2574 Rob Enns 2575 Juniper Networks 2576 1194 North Mathilda Ave 2577 Sunnyvale, CA 94089 2578 US 2580 EMail: rpe@juniper.net 2582 Appendix A. Capability Template 2584 A.1 capability-name (template) 2586 A.1.1 Overview 2588 A.1.2 Dependencies 2590 A.1.3 Capability and Namespace 2592 The {name} is identified by following capability string: 2594 http://ietf.org/xmlconf/1.0/base#{name} 2596 The {name} capability uses the base NETCONF namespace URI. 2598 A.1.4 New Operations 2600 A.1.4.1 2602 A.1.5 Modifications to Existing Operations 2604 A.1.5.1 2606 If existing operations are not modified by this capability, this 2607 section may be omitted. 2609 A.1.6 Interactions with Other Capabilities 2611 If this capability does not interact with other capabilities, this 2612 section may be omitted. 2614 Appendix B. Configuring Multiple Devices with NETCONF 2616 B.1 Operations on Individual Devices 2618 Consider the work involved in performing a configuration update 2619 against a single individual device. In making a change to the 2620 configuration, the application needs to build trust that its change 2621 has been made correctly and that it has not impacted the operation of 2622 the device. The application (and the application user) should feel 2623 confident that their change has not damaged the network. 2625 Protecting each individual device consists of a number of steps: 2627 o Acquiring the configuration lock. 2629 o Loading the update. 2631 o Validating the incoming configuration. 2633 o Checkpointing the running configuration. 2635 o Changing the running configuration. 2637 o Testing the new configuration. 2639 o Making the change permanent (if desired). 2641 o Releasing the configuration lock. 2643 Let's look at the details of each step. 2645 B.1.1 Acquiring the Configuration Lock 2647 A lock should be acquired to prevent simultaneous updates from 2648 multiple sources. If multiple sources are affecting the device, the 2649 application is hampered in both testing of its change to the 2650 configuration and in recovery should the update fail. Acquiring a 2651 short-lived lock is a simple defense to prevent other parties from 2652 introducing unrelated changes while. 2654 The lock can be acquired only if the device supports the #lock 2655 capability. The lock can be acquired using the operation. 2657 2658 2659 2660 2661 2662 2663 2665 If the #candidate capability is also supported, failure recovery can 2666 be simplified by using the parameter. 2668 2669 2670 automatic 2671 2672 2673 2674 2675 2677 B.1.2 Loading the Update 2679 The configuration can be loaded onto the device without impacting the 2680 running system. If the #url capability is supported, incoming 2681 changes can be placed in a local file. 2683 2684 2685 2686 2687 2688 2689 2690 2691 file://incoming.conf 2692 2693 text 2694 2695 2697 If the #candidate capability is supported, the candidate 2698 configuration can be used. 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2711 2713 If the update fails, the user file can be deleted using the 2714 operation or the candidate configuration reverted 2715 using the operation. 2717 B.1.3 Validating the Incoming Configuration 2719 Before applying the incoming configuration, it is often useful to 2720 validate it. Validation allows the application to gain confidence 2721 that the change will succeed and simplifies recovery if it does not. 2723 If the device supports the #url capability, use the 2724 operation with the parameter set to the proper user file: 2726 2727 2728 2729 file://incoming.conf 2730 2731 2732 2734 If the device supports the #candidate capability, some validation 2735 will be performed as part of loading the incoming configuration into 2736 the candidate. For full validation, either pass the 2737 parameter during the step given above, or use the 2738 operation with the parameter set to . 2740 2741 2742 2743 2744 2745 2746 2748 B.1.4 Checkpointing the Running Configuration 2750 The running configuration can be saved into a local file as a 2751 checkpoint before loading the new configuration. If the update 2752 fails, the configuration can be restored by reloading the checkpoint 2753 file. 2755 The checkpoint file can be created using the operation. 2757 2758 2759 2760 2761 2762 2763 file://checkpoint.conf 2764 2765 text 2766 2767 2769 To restore the checkpoint file, reverse the source and target 2770 parameters. 2772 B.1.5 Changing the Running Configuration 2774 When the incoming configuration has been safely loaded onto the 2775 device and validated, it is ready to impact the running system. 2777 If the device supports the #url capability, use the 2778 operation to merge the incoming configuration into the running 2779 configuration. 2781 2782 2783 2784 file://incoming.conf 2785 2786 2787 2788 2789 2790 2792 If the device supports the #candidate capability, use the 2793 operation to set the running configuration to the candidate 2794 configuration. Use the parameter to allow automatic 2795 reverting to the original configuration if connectivity to the device 2796 fails. 2798 2799 2800 2801 15 2802 2803 2805 B.1.6 Testing the New Configuration 2807 Now that the incoming configuration has been integrated into the 2808 running configuration, the application needs to gain trust that the 2809 change has affected the device in the way intended without affecting 2810 it negatively. 2812 To gain this confidence, the application can run tests of the 2813 operational state of the device. The nature of the test is dependent 2814 on the nature of the change and is outside the scope of this 2815 document. Such tests may include reachability from the system 2816 running the application (using ping), changes in reachability to the 2817 rest of the network (by comparing the device's routing table), or 2818 inspection of the particular change (looking for operational evidence 2819 of the BGP peer that was just added). 2821 B.1.7 Making the Change Permanent 2823 When the configuration change is in place and the application has 2824 sufficient faith in the proper function of this change, the 2825 application should make the change permanent. 2827 If the device supports the #startup capability, the current 2828 configuration can be saved to the startup configuration by using the 2829 startup configuration as the target of the operation. 2831 2832 2833 2834 2835 2836 2837 2838 2839 text 2840 2841 2843 If the device supports the #candidate capability and a confirmed 2844 commit was requested, the confirming commit must be sent before the 2845 timeout expires. 2847 2848 2849 2851 B.1.8 Releasing the Configuration Lock 2853 When the configuration update is complete, the lock must be released, 2854 allowing other applications access to the configuration. 2856 Use the operation to release the configuration lock. 2858 2859 2860 2862 B.2 Operations on Multiple Devices 2864 When a configuration change requires updates across a number of 2865 devices, care should be taken to provide the required transaction 2866 semantics. The NETCONF protocol contains sufficient primitives upon 2867 which transaction-oriented operations can be built. Providing 2868 complete transactional semantics across multiple devices is 2869 prohibitively expensive, but the size and number of windows for 2870 failure scenarios can be reduced. 2872 There are two classes of multidevice operations. The first class of 2873 allows the operation to fail on individual devices without requiring 2874 all devices to revert to their original state. The operation can be 2875 retried at a later time, or its failure simply reported to the user. 2876 A example of this class might be adding an NTP server. For this 2877 class of operations, failure avoidance and recovery are focused on 2878 the individual device. This means recovery of the device, reporting 2879 the failure, and perhaps scheduling another attempt. 2881 The second class is more interesting, requiring that the operation 2882 should complete on all devices or be fully reversed. The network 2883 should either be transformed into a new state or be reset to its 2884 original state. For example, a change to a VPN may require updates 2885 to a number of devices. Another example of this might be adding a 2886 class-of-service definition. Leaving the network in a state where 2887 only a portion of the devices have been updated with the new 2888 definition will lead to future failures when the definition is 2889 referenced. 2891 To give transactional semantics, the same steps used in single device 2892 operations listed above are used, but are performed in parallel 2893 across all devices. Configuration locks should be acquired on all 2894 target devices and kept until all devices are updated and the changes 2895 made permanent. Configuration changes should be uploaded and 2896 validation performed across all devices. Checkpoints should be made 2897 on each device. Then the running configuration can be changed, 2898 tested, and made permanent. If any of these steps fail, the previous 2899 configurations can be restored on any devices upon which it was 2900 changed. After the changes have been completely implemented or 2901 completely discarded, the locks on each device can be released. 2903 Intellectual Property Statement 2905 The IETF takes no position regarding the validity or scope of any 2906 intellectual property or other rights that might be claimed to 2907 pertain to the implementation or use of the technology described in 2908 this document or the extent to which any license under such rights 2909 might or might not be available; neither does it represent that it 2910 has made any effort to identify any such rights. Information on the 2911 IETF's procedures with respect to rights in standards-track and 2912 standards-related documentation can be found in BCP-11. Copies of 2913 claims of rights made available for publication and any assurances of 2914 licenses to be made available, or the result of an attempt made to 2915 obtain a general license or permission for the use of such 2916 proprietary rights by implementors or users of this specification can 2917 be obtained from the IETF Secretariat. 2919 The IETF invites any interested party to bring to its attention any 2920 copyrights, patents or patent applications, or other proprietary 2921 rights which may cover technology that may be required to practice 2922 this standard. Please address the information to the IETF Executive 2923 Director. 2925 Full Copyright Statement 2927 Copyright (C) The Internet Society (2003). All Rights Reserved. 2929 This document and translations of it may be copied and furnished to 2930 others, and derivative works that comment on or otherwise explain it 2931 or assist in its implementation may be prepared, copied, published 2932 and distributed, in whole or in part, without restriction of any 2933 kind, provided that the above copyright notice and this paragraph are 2934 included on all such copies and derivative works. However, this 2935 document itself may not be modified in any way, such as by removing 2936 the copyright notice or references to the Internet Society or other 2937 Internet organizations, except as needed for the purpose of 2938 developing Internet standards in which case the procedures for 2939 copyrights defined in the Internet Standards process must be 2940 followed, or as required to translate it into languages other than 2941 English. 2943 The limited permissions granted above are perpetual and will not be 2944 revoked by the Internet Society or its successors or assignees. 2946 This document and the information contained herein is provided on an 2947 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2948 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2949 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2950 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2951 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2953 Acknowledgement 2955 Funding for the RFC Editor function is currently provided by the 2956 Internet Society.