]>

meherrushi2@gmail.com

siddharth.bhat10@gmail.com

vartikatrao@gmail.com

hayyanhamnah@gmail.com

National Institute of Technology Karnataka, Surathkal

tahiliani@nitk.edu.in

Network Configuration cbor https yang This document extends by introducing CBOR encoding for YANG notifications over HTTPS in addition to the existing JSON and XML encoding schemes. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Network Configuration mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document introduces a CBOR encoding scheme for event notifications over HTTPS by using the framework proposed in which supports transfer of YANG notifications over HTTPS using JSON and XML encoding schemes. In , 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 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.

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 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the following terms defined in Section 2,3 and 4 of :

• Capabilities Resource
• Relay-Notification
• Event Notification

The following term(s) are defined in Subscription to YANG Notifications :

• Publisher
• Receiver
• Subscribed Notifications

The following term(s) are defined in Encoding of Data Modeled with YANG in the Concise Binary Object Representation (CBOR) :

• Diagnostic Notifications
• YANG Schema Item iDentifier (or "YANG SID" or simply "SID"): 63-bit unsigned integer used to identify different YANG items.

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 . 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 , and the keys of the encoded data use SID value as mentioned in 4.3.2 of this document.

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.

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

CBOR using names as keys Diagnostic Notation: CBOR Encoding:

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.

CBOR encoding using names as keys Diagnostic notation: Cbor Encoding:

CBOR encoding using SIDs as keys Diagnostic Notation: The above is assuming the YANG module for event notifications has a corresponding .sid file with these entries CBOR Encoding:

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.

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.

Security Considerations Addition of the CBOR encoding introduces no specific security exposures or risks other that the ones mentioned in and (An HTTPS-based Transport for YANG Notifications)

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 ) as requested in the draft . The following entry is added :

References Normative References Kloud Services Watsen Networks This document defines a protocol for sending asynchronous event notifications similar to notifications defined in RFC 5277, but over HTTPS. YANG modules for configuring publishers are also defined. Examples are provided illustrating how to configure various publishers. This document requires that the publisher is a "server" (e.g., a NETCONF or RESTCONF server), but does not assume that the receiver is a server. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. YANG (RFC 7950) is a data modeling language used to model configuration data, state data, parameters and results of Remote Procedure Call (RPC) operations or actions, and notifications. This document defines encoding rules for YANG in the Concise Binary Object Representation (CBOR) (RFC 8949). In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information. Watsen Networks This document presents two YANG modules: the first defines a minimal grouping for configuring an HTTP client, and the second defines a minimal grouping for configuring an HTTP server. It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete web servers or browsers). Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for this draft * JJJJ --> the assigned RFC value for draft-ietf-netconf-udp-client- server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2025-02-12 --> the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.1 contains a self- reference to this draft, along with a corresponding reference in the Appendix. Please replace the self-reference in this section with "This RFC" (or similar) and remove the self-reference in the "Normative/Informative References" section, whichever it is in. Tree-diagrams in this draft may use the '\' line-folding mode defined in RFC 8792. However, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggested suggested putting a request here for the RFC Editor to help convert "ugly" '\' folded examples to use the '\\' folding mode. "Help convert" may be interpreted as, identify what looks ugly and ask the authors to make the adjustment. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log Informative References This document describes a new sub-delegation for the 'ietf' URN namespace for registered protocol items. The 'ietf' URN namespace is defined in RFC 2648 as a root for persistent URIs that refer to IETF- defined resources. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

Acknowledgments The authors acknowlegde the support of Kent Watsen and Mahesh Jethanandani, the authors of for their guidance and support provided to draft this document.