]> National Institute of Technology Karnataka, Surathkal

meherrushi2@gmail.com

National Institute of Technology Karnataka, Surathkal

siddharth.bhat10@gmail.com

National Institute of Technology Karnataka, Surathkal

vartikatrao@gmail.com

National Institute of Technology Karnataka, Surathkal

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 Transport 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 GET requests, 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 defined in section 1 of Examples of the GET and POST request and reply encoded in CBOR are also provided.

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 only capable of receiving CBOR encoded messages the response would look like this

CBOR using names as keys Diagnostic Notation: CBOR Encoding: If the receiver is able to reply using “application/cbor” and assuming it is not capable of receiving cbor, but can receive both json and xml notifications:

CBOR using names as keys Diagnostic Notation: CBOR Encoding: If the receiver is unable to reply using "application/cbor", but is capable of receiving only cbor then the response might look like this:

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 "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.

Implementation Status This section records the status of known implementations of the specification defined by this document at the time of posting. The information is provided to assist the IETF in evaluating the maturity and implementability of the specification. This section will be removed prior to publication as an RFC.

Implementation: HTTPS Notification CBOR Draft Implementation

• Organization: National Institute of Technology Karnataka (NITK), Surathkal
• Implementation Name / Web Page: HTTPS Notification CBOR Draft Implementation https://github.com/MeherRushi/https-notif-draft-impl
• Description: This implementation provides a Python-based prototype of the mechanism defined in this document for transporting YANG notifications over HTTPS using JSON, XML and CBOR encoding. It supports name-based CBOR encoding (for now) and includes basic publisher and receiver roles to demonstrate end-to-end message exchange.
• Maturity Level: Prototype
• Coverage:
  • Capabilities discovery via HTTP GET to /capabilities
  • Event publication via HTTP POST to /relay-notification
  • Support for name-based CBOR encoding (for now) as described in this document
• Version Compatibility: The implementation is based on draft-ietf-netconf-https-notif-15 and draft-chittapragada-netconf-https-notif-cbor-03.
• Licensing: Freely distributable under an MIT-style license.
• Implementation Experience:
  • Developed and demonstrated at IETF 121 and 122 Hackathon.
  • Worked toward enabling CBOR encoding in the libyang library as part of the hackathon effort (slides).
  • Evaluated CBOR efficiency compared to JSON and XML in constrained environments.
  • Built tooling to simulate and measure notification transfer behavior over varying network conditions.
  • Diagnostic encoding examples used for validation of CBOR structures.
• Contact Information:
  • Bharadwaja Meherrushi Chittapragada (meher.211cs216@nitk.edu.in)
  • Vartika T Rao (vartikatrao.211it077@nitk.edu.in)
  • Siddharth Bhat (sidbhat.211ee151@nitk.edu.in)
  • Hayyan Arshad (hayyanarshad.211cs222@nitk.edu.in)
• Last Updated: July 24, 2025

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 that IANA include an additional entry in the “Capabilities for HTTPS Notification Receivers” registry, defined in , within the YANG Notifications registry group (as defined in ). 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). 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. 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 acknowledge the support of Kent Watsen and Mahesh Jethanandani, the authors of for their guidance and support provided to draft this document.