Network Configuration B. M. Chittapragada Internet-Draft Intended status: Standards Track S. Bhat Expires: 4 September 2025 V. T. Rao H. Arshad M. P. Tahiliani National Institute of Technology Karnataka, Surathkal 3 March 2025 CBOR Encoding for HTTPS-based Transport for YANG Notifications draft-chittapragada-netconf-https-notif-cbor-00 Abstract This document extends [I-D.draft-ietf-netconf-https-notif-15] by introducing CBOR encoding for YANG notifications over HTTPS in addition to the existing JSON and XML encoding schemes. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://MeherRushi.github.io/draft-chittapragada-netconf-https-notif- cbor/draft-chittapragada-netconf-https-notif-cbor.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-chittapragada-netconf-https- notif-cbor/. Discussion of this document takes place on the Network Configuration mailing list (mailto:netconf@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/netconf/. Subscribe at https://www.ietf.org/mailman/listinfo/netconf/. Source for this draft and an issue tracker can be found at https://github.com/MeherRushi/draft-chittapragada-netconf-https- notif-cbor. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Chittapragada, et al. Expires 4 September 2025 [Page 1] Internet-Draft https-notif-cbor March 2025 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 4 September 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. CBOR Encoding of the notification(s) . . . . . . . . . . . . 4 4.1. Capabilities Request . . . . . . . . . . . . . . . . . . 4 4.2. Capabilities Response . . . . . . . . . . . . . . . . . . 4 4.2.1. CBOR using names as keys . . . . . . . . . . . . . . 4 4.3. Relay Notification request . . . . . . . . . . . . . . . 5 4.3.1. CBOR encoding using names as keys . . . . . . . . . . 5 4.3.2. CBOR encoding using SIDs as keys . . . . . . . . . . 6 4.4. Relay Notification Response . . . . . . . . . . . . . . . 8 5. Scope of Experimentation . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Chittapragada, et al. Expires 4 September 2025 [Page 2] Internet-Draft https-notif-cbor March 2025 1. Introduction This document introduces a CBOR encoding scheme for event notifications over HTTPS by using the framework proposed in [I-D.draft-ietf-netconf-https-notif-15] which supports transfer of YANG notifications over HTTPS using JSON and XML encoding schemes. In [I-D.draft-ietf-netconf-https-notif-15], the capabilities HTTP- target resource allows a publisher to retrieve supported encoding formats via a GET request, while the relay-notification resource enables the publisher to send YANG notifications via POST requests. These requests and responses use different content types based on the selected encoding scheme. This document defines support for using CBOR encoding as mentioned in section 1 of [I-D.draft-ietf-netconf-https-notif-15] CBOR offers an efficient and compact representation of YANG notifications. Examples of the GET and POST request and reply encoded in CBOR are also provided. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Terminology This document uses the following terms defined in Section 2,3 and 4 of [I-D.draft-ietf-netconf-https-notif-15]: * Capabilities Resource * Relay-Notification * Event Notification The following term(s) are defined in Subscription to YANG Notifications [RFC8639]: * Publisher * Receiver Chittapragada, et al. Expires 4 September 2025 [Page 3] Internet-Draft https-notif-cbor March 2025 * Subscribed Notifications The following term(s) are defined in Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR) [RFC9254]: * Diagnostic Notifications * YANG Schema Item iDentifier (or "YANG SID" or simply "SID"): 63-bit unsigned integer used to identify different YANG items. 4. CBOR Encoding of the notification(s) YANG notifications can be encoded in CBOR using Names or SIDs in keys. Notifications encoded using names is similar to JSON encoding as defined in Section 3.4 and 4.3 of [I-D.draft-ietf-netconf-https-notif-15]. Notification encoded using YANG-SIDs replaces the names of the keys of the CBOR encoded message with a 63 bit unsigned integer. In this case, the term 'SID' is defined in Section 3.2 of [RFC9254], and the keys of the encoded data use SID value as mentioned in 4.3.2 of this document. 4.1. Capabilities Request The publisher sends a request to the receiver to learn its capabilities. In the below example, the “Accept” states that the publisher wants to receive the capabilities response in CBOR but if not supported then in XML or JSON in that order. GET /some/path/capabilities HTTP/1.1 Host: example.com Accept: application/cbor, application/xml;0.9, application/json;q=0.5 4.2. Capabilities Response If the receiver is able to reply using “application/cbor” and assuming it is capable of receiving JSON, XML and CBOR encoded messages the response would look like this 4.2.1. CBOR using names as keys Diagnostic Notation: Chittapragada, et al. Expires 4 September 2025 [Page 4] Internet-Draft https-notif-cbor March 2025 HTTP/1.1 200 OK Date: Tue, 4 March 2025 20:33:30 GMT Server: example-server Cache-Control: no-cache Content-Type: application/json { "receiver-capabilities": { "receiver-capability": [ "urn:ietf:capability:https-notif-receiver:encoding:json", "urn:ietf:capability:https-notif-receiver:encoding:xml", "urn:ietf:capability:https-notif-receiver:encoding:cbor" ] } } CBOR Encoding: A1 # map(1) 75 # text(21) 72656365697665722D6361706162696C6974696573 # "receiver-capabilities" A1 # map(1) 73 # text(19) 72656365697665722D6361706162696C697479 # "receiver-capability" 83 # array(3) 78 36 # text(54) 75726E3A696574663A6361706162696C6974793A68747470732D6E6F7469662D72656365697665723A656E636F64696E673A6A736F6E # "urn:ietf:capability:https-notif-receiver:encoding:json" 78 35 # text(53) 75726E3A696574663A6361706162696C6974793A68747470732D6E6F7469662D72656365697665723A656E636F64696E673A786D6C # "urn:ietf:capability:https-notif-receiver:encoding:xml" 78 36 # text(54) 75726E3A696574663A6361706162696C6974793A68747470732D6E6F7469662D72656365697665723A656E636F64696E673A63626F72 # "urn:ietf:capability:https-notif-receiver:encoding:cbor" 4.3. Relay Notification request The publisher sends an HTTP POST request to the "relay-notification" resource on the receiver with the "Content-Type" header set to either "application/cbor" in case the receiver is CBOR capable and a body containing the notification encoded in CBOR. 4.3.1. CBOR encoding using names as keys POST /some/path/relay-notification HTTP/1.1 Host: example.com Content-Type: application/cbor Diagnostic notation: Chittapragada, et al. Expires 4 September 2025 [Page 5] Internet-Draft https-notif-cbor March 2025 { "ietf-https-notif:notification": { "eventTime": "2013-12-21T00:01:00Z", "example-mod:event" : { "event-class" : "fault", "reporting-entity" : { "card" : "Ethernet0" }, "severity" : "major" } } } Cbor Encoding: A1 # map(1) 78 1D # text(29) 696574662D68747470732D6E6F7469663A6E6F74696669636174696F6E # "ietf-https-notif:notification" A2 # map(2) 69 # text(9) 6576656E7454696D65 # "eventTime" 74 # text(20) 323031332D31322D32315430303A30313A30305A # "2013-12-21T00:01:00Z" 71 # text(17) 6578616D706C652D6D6F643A6576656E74 # "example-mod:event" A3 # map(3) 68 # text(8) 7365766572697479 # "severity" 65 # text(5) 6D616A6F72 # "major" 6B # text(11) 6576656E742D636C617373 # "event-class" 65 # text(5) 6661756C74 # "fault" 70 # text(16) 7265706F7274696E672D656E74697479 # "reporting-entity" A1 # map(1) 64 # text(4) 63617264 # "card" 69 # text(9) 45746865726E657430 # "Ethernet0" 4.3.2. CBOR encoding using SIDs as keys Diagnostic Notation: Chittapragada, et al. Expires 4 September 2025 [Page 6] Internet-Draft https-notif-cbor March 2025 { 2600: { 1: "2013-12-21T00:01:00Z", "example-mod:event" : { "event-class" : "fault", "reporting-entity" : { "card" : "Ethernet0" }, "severity" : "major" } } } The above is assuming the YANG module for event notifications has a corresponding .sid file with these entries "item": [ { "namespace": "module", "identifier": "ietf-notification", "sid": "2600" }, { "namespace": "data", "identifier": "/ietf-notification:notification", "sid": "2601" }, { "namespace": "data", "identifier": "/ietf-notification:notification/eventTime", "sid": "2602" } ] CBOR Encoding: Chittapragada, et al. Expires 4 September 2025 [Page 7] Internet-Draft https-notif-cbor March 2025 A1 # map(1) 19 0A28 # unsigned(2600) A2 # map(2) 01 # unsigned(1) 74 # text(20) 323031332D31322D32315430303A30313A30305A # "2013-12-21T00:01:00Z" 71 # text(17) 6578616D706C652D6D6F643A6576656E74 # "example-mod:event" A3 # map(3) 68 # text(8) 7365766572697479 # "severity" 65 # text(5) 6D616A6F72 # "major" 6B # text(11) 6576656E742D636C617373 # "event-class" 65 # text(5) 6661756C74 # "fault" 70 # text(16) 7265706F7274696E672D656E74697479 # "reporting-entity" A1 # map(1) 64 # text(4) 63617264 # "card" 69 # text(9) 45746865726E657430 # "Ethernet0" 4.4. Relay Notification Response The response on success is "204 (No Content)". In case of corrupted or malformed event, the response is an appropriate HTTP error response. 5. Scope of Experimentation CBOR encoding may be tested against JSON and XML to evaluate requests per second, data transfer rate, and overall network efficiency. Bandwidth constraints can be applied using traffic control to analyze CBOR encoding efficiency under different network conditions. 6. Security Considerations Addition of the CBOR encoding introduces no specific security exposures or risks other that the ones mentioned in [RFC9254] and [I-D.draft-ietf-netconf-https-notif-15] (An HTTPS-based Transport for YANG Notifications) Chittapragada, et al. Expires 4 September 2025 [Page 8] Internet-Draft https-notif-cbor March 2025 7. IANA Considerations This document requests the the IANA registry to include an additional entry to the proposed initial assignments in the “Capabilities for HTTPS Notification Receivers” registry within the YANG Notifications registry group(defined in [RFC3553]) as requested in the draft [I-D.ietf-netconf-http-client-server]. The following entry is added : Record: URN: urn:ietf:params:yang-notif:https-capability:encoding:cbor Reference: RFC XXXX:An HTTPS-based Transport for YANG Notifications Description: Identifies support for CBOR-encoded notifications. 8. References 8.1. Normative References [I-D.draft-ietf-netconf-https-notif-15] Jethanandani, M. and K. Watsen, "An HTTPS-based Transport for YANG Notifications", Work in Progress, Internet-Draft, draft-ietf-netconf-https-notif-15, 1 February 2024, . [I-D.ietf-netconf-http-client-server] Watsen, K., "YANG Groupings for HTTP Clients and HTTP Servers", Work in Progress, Internet-Draft, draft-ietf- netconf-http-client-server-25, 12 February 2025, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8639] Voit, E., Clemm, A., Gonzalez Prieto, A., Nilsen-Nygaard, E., and A. Tripathy, "Subscription to YANG Notifications", RFC 8639, DOI 10.17487/RFC8639, September 2019, . Chittapragada, et al. Expires 4 September 2025 [Page 9] Internet-Draft https-notif-cbor March 2025 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9254] Veillette, M., Ed., Petrov, I., Ed., Pelov, A., Bormann, C., and M. Richardson, "Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR)", RFC 9254, DOI 10.17487/RFC9254, July 2022, . 8.2. Informative References [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, . Acknowledgments The authors acknowlegde the support of Kent Watsen and Mahesh Jethanandani, the authors of [I-D.draft-ietf-netconf-https-notif-15] for their guidance and support provided to draft this document. Authors' Addresses Bharadwaja Meherrushi Chittapragada Email: meherrushi2@gmail.com Siddharth Bhat Email: siddharth.bhat10@gmail.com Vartika T Rao Email: vartikatrao@gmail.com Hayyan Arshad Email: hayyanhamnah@gmail.com Mohit P. Tahiliani National Institute of Technology Karnataka, Surathkal Email: tahiliani@nitk.edu.in Chittapragada, et al. Expires 4 September 2025 [Page 10]