idnits 2.17.1 draft-varga-netconf-exi-capability-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2013) is 3942 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group R. Varga 3 Internet-Draft Pantheon Technologies SRO 4 Intended status: Standards Track July 11, 2013 5 Expires: January 10, 2014 7 Efficient XML Interchange Capability for NETCONF 8 draft-varga-netconf-exi-capability-00 10 Abstract 12 The Network Configuration Protocol (NETCONF) provides mechanisms to 13 install, manipulate, and delete the configuration of network devices 14 via exchange of XML messages in textual representation. Efficient 15 XML Interchange (EXI) is a W3C-recommended binary representation of 16 XML Information Set, which is more efficient from both CPU and 17 bandwidth utilization perspective. This document defines a 18 capability-based extension to the NETCONF protocol that allows peers 19 to agree to exchange protocol messages using EXI encoding. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 10, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. EXI Capability . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3.2. Dependencies . . . . . . . . . . . . . . . . . . . . . . . 3 66 3.3. Capability Identifier . . . . . . . . . . . . . . . . . . 3 67 3.4. New Operations . . . . . . . . . . . . . . . . . . . . . . 4 68 3.4.1. . . . . . . . . . . . . . . . . . . . . . 4 69 3.4.2. . . . . . . . . . . . . . . . . . . . . . . 5 70 4. YANG module for and Operations . . . . 6 71 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 6 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 74 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 The NETCONF protocol [RFC6241] is defined in terms of two peers, 80 client and server, exchanging XML messages in an RPC pattern. These 81 messages are encoded as XML text documents, which makes the exchange 82 easily understandable by human operators by simply observing them on 83 the wire. Unfortunately, this feature takes its toll on both 84 computation and network resources, as the representation contains 85 redundant information and verbose names. 87 Efficient XML Interchange [W3C.REC-exi-20110310] is a W3C 88 Recommendation which defines a more efficient way of encoding XML 89 Information Set than the usual text representation. This is achieved 90 by a combination of reduced verbosity, binary encoding and, 91 optionally, pruning of non-essential information like comments. 93 It seems advantageous to allow clients and servers participating on a 94 NETCONF session to sacrifice human readability to increase processing 95 efficiency, especially in environments with high transactional 96 activity and/or limited computing resources. 98 2. Terminology 100 This document uses the following terms defined in [RFC6241]: 102 o capability 104 o client 106 o message 108 o protocol operation 110 o remote procedure call 112 o server 114 3. EXI Capability 116 3.1. Overview 118 The :exi capability indicates that the peer supports EXI message 119 encoding and is willing to use it. The capability has no effect on 120 data being handled by the NETCONF protocol, nor does it affect 121 protocol message exchanges. 123 3.2. Dependencies 125 EXI-encoded documents are binary data, this capability may only be 126 used when the underlying transport is 8-bit clean and preserves 127 message boundaries in face of arbitrary binary data. Notably this 128 requires use of Chunked Framing mechanism as described in [RFC6242] 129 when used with SSH transport. 131 3.3. Capability Identifier 133 The EXI capability is identified by the following capability string: 135 urn:ietf:params:netconf:capability:exi:1.0 137 The identifier MAY have a the following parameters: 139 compression: This indicates that the sender is willing to perform EXI 140 compression. The parameter MUST contain a positive integral 141 value, which indicates maximum compression block size which the 142 sender can process. 144 schemas: This indicates that the sender can use schema-informed 145 grammars for EXI encoding. The parameter MUST contain a value, 146 which has to be one of "builtin" or "base:1.1". The value 147 "builtin" indicates the ability to use the XML schema built into 148 the EXI specification. The value of "base:1.1" is a superset of 149 the "builtin" value and indicates that the sender additionally 150 supports schema-informed EXI encoding, based on netconf.xsd schema 151 published in [RFC6241]. 153 Examples: 155 urn:ietf:params:netconf:capability:exi:1.0?compression=1000000 157 urn:ietf:params:netconf:capability:exi:1.0?schemas=builtin 159 urn:ietf:params:netconf:capability:exi:1.0?schemas=base:1.1 161 urn:ietf:params:netconf:capability:exi:1.0?compression=20000&schem 162 as=builtin 164 3.4. New Operations 166 3.4.1. 168 Description: The operation requests that the message 169 encoding be switched to EXI. The operation is invoked by the 170 client and validated by the server. If the server finds the 171 parameters acceptable, it will issue a positive response in the 172 current session encoding. It MUST encode all subsequent messages 173 using EXI encoding with the supplied parameters. It will also 174 expect all incoming messages to be EXI-encoded. The client MUST 175 NOT send any messages to the server between the time is sends this 176 request and the time it receives a response. Once it receives a 177 positive reply, it MUST encode all subsequent messages using the 178 EXI encoding with the parameters supplied in the RPC. If the 179 operation fails, the session message encoding remains unchanged. 181 Parameters: 183 alignment: Requested EXI alignment. If this parameter is not 184 present, bit-packed is assumed. The following values are 185 valid: 187 bit-packed: Set EXI alignment to bit-packed. 189 byte-aligned: Set EXI alignment to byte-aligned. 191 pre-compression: Set EXI alignment to pre-compression. 193 compressed: Do not specify EXI alignment, but perform EXI 194 compression instead. 196 fidelity: Requested EXI fidelity options. If this parameter is 197 not present or empty, all fidelity options are disabled. The 198 following items may be specified: 200 : EXI Preserve.comments 202 : EXI Preserve.dtd 204 : EXI Preserve.lexicalValues 206 : EXI Preserve.pis 208 : EXI Preserve.prefixes 210 Positive Response: If the device was able to satisfy the request, an 211 is sent that contains an element. 213 Negative Response: An element is included in the if the request cannot be completed for any reason. 216 Example: 218 220 221 pre-compression 222 223 224 225 226 227 229 231 232 234 3.4.2. 235 Description: The operation requests that the message 236 encoding be switched to textual XML. The operation is invoked by 237 the client and validated by the server. If the server is able to 238 switch the encoding to XML, it will issue a positive response in 239 the current session encoding. It MUST encode all subsequent 240 messages using standard XML encoding. It will also expect all 241 incoming messages to be XML-encoded. The client MUST NOT send any 242 messages to the server between the time is sends this request and 243 the time it receives a response. Once it receives a positive 244 reply, it MUST encode all subsequent messages using the standard 245 XML encoding. If the operation fails, the session message 246 encoding remains unchanged. If the session currently uses XML 247 encoding, this RPC is a no-operation and SHOULD NOT fail. 249 Positive Response: If the device was able to satisfy the request, an 250 is sent that contains an element. 252 Negative Response: An element is included in the if the request cannot be completed for any reason. 255 Example: 257 259 260 262 264 265 267 4. YANG module for and Operations 269 The following YANG module defines the new operations introduced in 270 this document. The YANG language is defined in [RFC6020]. Every 271 NETCONF speaker that supports the :exi capability MUST implement this 272 YANG module. 274 TBD. 276 5. IANA considerations 278 This document registers the following capability identifier URN in 279 the 'Network Configuration Protocol (NETCONF) Capability URNs' 280 registry: urn:ietf:params:netconf:capability:exi:1.0 282 6. Security Considerations 284 The compression option present in EXI specification may increase CPU 285 and memory requirements for encoding the response. Devices should 286 ensure this overhead is acceptable before agreeing to using EXI 287 encoding, such that no operational risks are introduced. 289 7. Acknowledgements 291 The author would like to thank Anton Tkacik, Miroslav Miklus and 292 Stefan Kobza for their contributions to this document. 294 8. Normative References 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, March 1997. 299 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 300 Network Configuration Protocol (NETCONF)", RFC 6020, 301 October 2010. 303 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 304 Bierman, "Network Configuration Protocol (NETCONF)", RFC 305 6241, June 2011. 307 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 308 Shell (SSH)", RFC 6242, June 2011. 310 [W3C.REC-exi-20110310] 311 Schneider, J. and T. Kamiya, "Efficient XML Interchange 312 (EXI) Format 1.0", World Wide Web Consortium 313 Recommendation REC-exi-20110310, March 2011, . 316 Author's Address 318 Robert Varga 319 Pantheon Technologies SRO 320 Mlynske Nivy 56 321 Bratislava 821 05 322 Slovakia 324 Email: robert.varga@pantheon.sk