CBOR Encoding for HTTPS-based YANG Notifications Transport

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 4.1 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. The "application/yang-data+cbor" media type used throughout this document is defined in Section 9 of . That registration also defines the "id" parameter: "application/yang-data+cbor; id=name" for the name-based keys described in this document, and "application/yang-data+cbor; id=sid" for the SID-based keys.

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/yang-data+cbor” and assuming it is only capable of receiving CBOR encoded messages the response would look like this

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

CBOR using names as keys (receiver accepts JSON and XML) Diagnostic Notation: CBOR Encoding: If the receiver cannot encode the capabilities response in "application/yang-data+cbor" but is itself only able to receive CBOR-encoded notifications, it replies using JSON (or XML) while still advertising the CBOR capability:

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/yang-data+cbor" in case the receiver is CBOR capable and a body containing the notification encoded in CBOR. The "id" parameter of the media type indicates whether the keys are encoded as names ("id=name") or as SIDs ("id=sid").

CBOR encoding using names as keys Diagnostic Notation: CBOR Encoding:

CBOR encoding using SIDs as keys Diagnostic Notation: The above assumes that the YANG modules for the notification envelope and for the event have corresponding .sid files with the following entries: The SID values shown above are illustrative examples only; they are not SIDs registered for any real YANG module. A deployment uses the SIDs actually assigned to the modules involved. Keys are encoded as SID deltas relative to the reference SID of the enclosing map, as defined in Section 3.2 of . Because "example-mod:event" is defined in a different module than its parent, its delta is large (60001 - 2601 = 57400); alternatively, it MAY be encoded as an absolute SID using CBOR tag 47. CBOR Encoding:

Relay Notification Response The response on success SHOULD be from the 2XX class of codes. In case of corrupted or malformed event, the response SHOULD be an appropriate HTTP error response.

Legacy RFC 5277 Notifications defines optional support for sending legacy notifications, as defined in NETCONF Event Notifications , using the "application/xml" media type. This legacy mode exists for interoperability with publishers that are not aware of YANG media types; a receiver advertises support for it using the "urn:ietf:params:yang-notif:https-capability:rfc5277-notif" capability. The CBOR encoding defined in this document applies to YANG-modeled notifications, including the eventTime envelope, and is advertised using the "urn:ietf:params:yang-notif:https-capability:encoding:cbor" capability registered by this document. Because defines the legacy RFC 5277 mode as XML-only, this document does not define a CBOR variant of it. A publisher that is able to produce CBOR is YANG-aware and therefore uses the CBOR encoding described here rather than the legacy mode.

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
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 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 as described in this document
Version Compatibility: The implementation is based on draft-ietf-netconf-https-notif-16 and draft-ietf-netconf-https-notif-cbor-00.
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