[netconf] Re: draft-ietf-netconf-https-notif-cbor-00: Update and request for further review and clarification

[Kent Watsen <[e-mail]>]

Alex, Meher, all,

The https-notif authors are in the process of making this change, but please help me confirm that the new media-type is accurate for legacy notifications, which are technically not modeled by YANG.  I think that calling it "yang-data" anyways makes sense, for all of the benefits mentioned.  Perhaps the "https-notif" draft needs to explicitly mention it?

Kent // https-notif contributor



> On May 10, 2026, at 6:45 AM, Alex Huang Feng <[e-mail]> wrote:
> 
> Dear Meher,
> 
> [Adding HTTPS-Notif authors, AD and shepherd as the https-notif document is currently at the IESG]
> 
> I already went to the mic in IETF 125 (https://datatracker.ietf.org/doc/minutes-125-netconf-202603160100/) to comment this, but forgot to send my mail to the ML.
> 
> I strongly suggest going option 1. 
> Any data that is YANG-modelled needs to use application/yang-data+[xml/json/cbor] rather than the generic application/[xml/json/cbor].
> The reason is because they follow different specifications. CBOR follows RFC8948 and YANG-CBOR follows RFC9254. Thus, I would strongly suggest the community to keep consistency here.
> 
> Additionally, as Meher noted below, if we use application/yang-data-cbor, identifying name-encoded messages and SID-encoded messages becomes automatic (by using the id parameter). 
> 
> As per the approach to solve this I would let the chairs and WG decide. 
> I know https-notif draft is currently at the IESG, but Kent suggested at IETF125 to bring https-notif back to the WG to quickly change the two encodings:
> - application/xml —> application/yang-data+xml [RFC8040]
> - application/json —> application/yang-data-json [RFC8040]
> 
> I would prefer this option, so that we can keep the documents consistent.
> If the document cannot be brought back to the WG, the second option would be to use draft-ietf-netconf-https-notif-cbor to ‘update' draft-ietf-netconf-https-notif.
> 
> Regarding the capabilities exchange using YANG, it may be worth to have a look at https://datatracker.ietf.org/doc/draft-ietf-netconf-yp-transport-capabilities/
> This YANG module uses the encodings from subscribed-notifications, so any identify coming from “sn:encoding” can be exchanged between the server and the client.
> 
> Regards,
> Alex
> 
>> On 10 Mar 2026, at 07:18, Meher Rushi <[e-mail]> wrote:
>> 
>> Hi all,
>> 
>> Thank you to everyone who participated in the adoption call and IPR poll. Our document is now available as a WG item:
>> 
>>   draft-ietf-netconf-https-notif-cbor-00
>>   https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif-cbor/
>> 
>> As a brief reminder, this document extends draft-ietf-netconf-https-notif by adding CBOR encoding support for YANG notifications over HTTPS transport, complementing the existing JSON and XML encodings.
>> 
>> Based on the previous discussions and comments, we would like to bring the following question to the list to decide on the appropriate modification to make to the draft.
>> 
>> As we continued working through the implementation, we realized we need to explicitly signal whether a CBOR payload uses name-based or SID-based encoding. Without this, a receiver has no reliable way to distinguish the two from inspection alone, and misidentification causes decoding failures.
>> 
>> The media type application/yang-data+cbor (RFC 9254) is designed for exactly this: it supports an optional "id" parameter (id=name or id=sid) for unambiguous signaling. However, RFC 9254 also specifies that this media type is intended only for YANG-modeled data, which introduces a constraint described below.
>> 
>> This leads to two candidate approaches:
>> 
>> Option 1 — Use application/yang-data+cbor with the id parameter
>>   Provides standardized, unambiguous signaling aligned with RFC 9254.
>>   The constraint is that applying it to the capability exchange requires
>>   a corresponding YANG module — which the current https-notif draft does
>>   not define. However, draft-ietf-netconf-notif-envelope
>>   (https://datatracker.ietf.org/doc/draft-ietf-netconf-notif-envelope/)
>>   is already introducing an extensible YANG model for notification
>>   envelopes in this space, which suggests that defining a YANG module
>>   for the capability exchange may be a natural and reasonable step.
>>   If taken, it may also be worth updating the parent https-notif draft
>>   to use application/yang-data+json and application/yang-data+xml for
>>   consistency, though that would be a separate and non-trivial change.
>> 
>> Option 2 — Keep application/cbor; signal encoding via capability URIs
>>   Retain application/cbor for both capability exchange and notifications.
>>   Signal the SID vs. name distinction through dedicated capability URIs
>>   in the capability exchange response, e.g.:
>>     urn:ietf:capability:https-notif-receiver:encoding:cbor:sid
>>     urn:ietf:capability:https-notif-receiver:encoding:cbor:named_identifier
>>   The draft already permits custom capability URIs, and publishers are
>>   required to ignore unrecognised ones, so this requires no structural
>>   changes to either draft. The tradeoff is relying on URI convention
>>   rather than the standardized media-type mechanism — though it fully
>>   resolves the ambiguity. Given that the capability exchange is a
>>   one-time event per session, the performance difference between the
>>   two options is negligible.
>> 
>> We would appreciate WG input on both options, particularly from those
>> familiar with SIDs and CBOR. We welcome further review and feedback from the WG. If you have comments, please send them to this list or open an issue on our GitHub tracker:
>> https://github.com/MeherRushi/draft-ietf-netconf-https-notif-cbor
>>  <https://github.com/MeherRushi/draft-ietf-netconf-https-notif-cbor>
>> Best regards,
>> Bharadwaja Meherrushi Chittapragada, Siddharth Bhat, Vartika T Rao,
>> Hayyan Arshad, Mohit P. Tahiliani
>> (Authors, draft-ietf-netconf-https-notif-cbor)
>> _______________________________________________
>> netconf mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>