idnits 2.17.1 draft-mahesh-netconf-binary-encoding-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6241]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 122: '...g capability URI MUST contain a "forma...' RFC 2119 keyword, line 146: '... MUST fail with the valu...' -- The abstract seems to indicate that this document updates RFC6241, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 23, 2018) is 2253 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) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-06 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF WG M. Jethanandani 3 Internet-Draft 4 Intended status: Standards Track J. Lam 5 Expires: August 27, 2018 A. Leung 6 Cisco Systems, Inc. 7 February 23, 2018 9 Binary Encoding for NETCONF 10 draft-mahesh-netconf-binary-encoding-00 12 Abstract 14 This document describes a method by which a NETCONF [RFC6241] client 15 and server can negotiate an alternate form of encoding. 17 This document updates RFC 6241. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 27, 2018. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 2 55 2. Protocol Negotiation . . . . . . . . . . . . . . . . . . . . 2 56 2.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1.2. Dependencies . . . . . . . . . . . . . . . . . . . . 3 59 2.1.3. Capability Identifier . . . . . . . . . . . . . . . . 3 60 2.1.4. New Operation . . . . . . . . . . . . . . . . . . . . 3 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. NETCONF Capability URNs . . . . . . . . . . . . . . . . . 5 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 67 6.2. Informative References . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 NETCONF [RFC6241], by default, supports XML encoding for its payload. 73 However, XML can be very verbose, specially for operational data. 74 That combined with parsing of tags leads to slow processing of the 75 data. This document proposes a mechanism by which clients and 76 servers can negotiate an alternate form of encoding, e.g. binary 77 encoding, and use that to exchange data. Binary encoding can reduce 78 the physical size of the data exchanged, in some cases by as much as 79 66%, and improve the time that is required to process the data, while 80 preserving the original data. 82 Several binary encoding mechanisms have been proposed, including CBOR 83 [RFC7049]. This document does not advocate any particular binary 84 encoding format. Instead, it leaves it up to the negotiation between 85 client and server to decide the form of encoding. For an example of 86 how to encode YANG in CBOR format, see CBOR Encoding of Data Modeled 87 with YANG [I-D.ietf-core-yang-cbor]. 89 1.1. Definitions and Acronyms 91 2. Protocol Negotiation 93 NETCONF clients and servers exchange a hello as part of establishing 94 a connection. As part of the hello exchange, each of them advertises 95 their set of capabilities. This draft suggests advertisement of the 96 following additional capability. 98 2.1. Encoding 100 2.1.1. Overview 102 The :encoding capability indicates what encoding format each side is 103 willing to support. If the client and server are capable of 104 supporting multiple forms of encoding, they can list each of them. 105 There is no need to include xml in the list, as that is supported by 106 default. 108 2.1.2. Dependencies 110 When using this capability, any binardy encoding needs the underlying 111 transport to be 8-bit clean, and which preserves message boundaries 112 when dealing with arbitrary binary data. This requires use of 113 Chunked Framing mechanism as described in NETCONF over SSH [RFC6242]. 115 2.1.3. Capability Identifier 117 The :encoding capability is identfied by the following capability 118 string: 120 urn:ietf:params:netconf:capability:encoding:1.0?format={name, ...} 122 The :encoding capability URI MUST contain a "format" argument 123 assigned a comma-separated list of formats supported by the device. 124 For example: 126 urn:ietf:params:netconf:capability:encoding:1.0?format=cbor,gpb,thrif 127 t 129 2.1.4. New Operation 131 2.1.4.1. 133 Description: 135 After each side has exchanged capabilities, a client can initiate a 136 request to switch to a new encoding format using the 137 operation. 139 Parameters: 141 encoding: 143 The operation instructs the server to switch to the new 144 binary format. If the server does not support the new binary format 145 or is unable to switch to the new binary format for any reason, it 146 MUST fail with the value of "not-supported" and keep the 147 existing encoding format it is using. 149 If the system does not have the :encoding capability, the 150 operation is not available. If there is a desire to fall back to 151 default encoding of XML, the client needs to terminate the existing 152 connection and establish a new connection. 154 Positive Response: 156 If the device is able to satisfy the requests, an is sent 157 that contains an element. 159 Negative Response: 161 An element is included in the with the 162 element set to "not-supported". The element must be set 163 to "server-error". 165 Example: 167 169 170 cbor 171 172 174 176 177 179 3. Security Considerations 181 4. IANA Considerations 183 This document registers a URI in the IETF XML registry [RFC3688]. 184 Following the format in RFC 3688, the following registration is 185 requested to be made: 187 4.1. NETCONF Capability URNs 189 IANA registry "Network Configuration Protocol (NETCONF) Capability 190 URNs" needs to be updated to include the following capability. 192 Index 193 Capability Identifier 194 ------------------------- 195 :encoding 196 urn:ietf:params:netconf:capability:encoding:1.0 198 5. Acknowledgements 200 6. References 202 6.1. Normative References 204 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 205 DOI 10.17487/RFC3688, January 2004, 206 . 208 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 209 and A. Bierman, Ed., "Network Configuration Protocol 210 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 211 . 213 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 214 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 215 . 217 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 218 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 219 October 2013, . 221 6.2. Informative References 223 [I-D.ietf-core-yang-cbor] 224 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 225 Minaburo, "CBOR Encoding of Data Modeled with YANG", 226 draft-ietf-core-yang-cbor-06 (work in progress), February 227 2018. 229 Authors' Addresses 231 Mahesh Jethanandani 233 Email: mjethanandani@gmail.com 234 Jason Lam 235 Cisco Systems, Inc. 237 Email: lamj@cisco.com 239 Alfred Leung 240 Cisco Systems, Inc. 242 Email: alfleung@cisco.com