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

[Meher Rushi <[e-mail]>]

Hi Mahesh,

Thanks a lot for the update to the draft-ietf-netconf-https-notif. Yes, we
plan to update the draft-ietf-netconf-https-notif-cbor and present it in
126. Prof. Mohit has requested for a slot on behalf of us. We shall update
the draft and send the presentation in soon.

Regards,
Meher and Team

On Fri, Jul 3, 2026 at 8:47 PM Mahesh Jethanandani <[e-mail]>
wrote:

> Hi Mehir,
>
> draft-ietf-netconf-https-notif has now been updated to support
> application/yang-data+[xml|json]. You should be able to add support for
> application/yang-data+cbor.
>
> Do you have a plan to update your draft and present it in 126?
>
> Cheers.
>
> On May 14, 2026, at 4:12 PM, Mahesh Jethanandani <[e-mail]>
> wrote:
>
> Hi Alex/Meher,
>
> I had started to put together some of the changes requested by the Meher
> and authors of the CBOR draft. These were done before Alex sent his email
> and the response from Kent. So the changes do not reflect that discussion.
> With that in mind, here is the PR to review and confirm if these changes
> would satisfy the initial ask (for new notifications). If support for
> legacy notifications is needed, the draft will need to bring back some of
> the changes, but that is hopefully not big.
>
> [image: 56.png]
>
> Add support for yang-data+xml and yang-data+json by mjethanandani · Pull
> Request #56 · netconf-wg/https-notif
> <https://github.com/netconf-wg/https-notif/pull/56>
> github.com <https://github.com/netconf-wg/https-notif/pull/56>
> <https://github.com/netconf-wg/https-notif/pull/56>
>
> Thanks.
>
> On May 14, 2026, at 12:28 PM, Kent Watsen <[e-mail]> wrote:
>
> Thanks for the confirmation, Alex.
>
> Would the issue resolve if the https-notif draft supports both as follows?
>     - use application/xml for legacy notifications
>     - use application/yang-data+xml for new notifications
>
> Kent
>
>
> On May 14, 2026, at 10:30 AM, Alex Huang Feng <
> [e-mail]> wrote:
>
> Dear Kent, authors, all,
>
> For legacy notifications [RFC5277], the modelling uses xml rather than
> YANG, so I am also unsure if yang-data+xml is totally correct in this case.
> However, I agree with you and would still suggest to use
> application/yang-data+xml.
> The https-notif specification uses the keyword "yang" a bit of everywhere.
> The IANA registry is "YANG Notifications” and “yang-notif", rather than
> just “Notifications”. So for consistency, application/yang-data+xml makes
> more sense.
>
> A sentence in Section 1.1 (Applicability Statement) can definitely help.
> However, note that while this section states that this spec can be used
> outside RFC8639, it suggests to remain within a YANG environment (creating
> a new YANG module based on I-D.ietf-netconf-http-client-server).
> So, I’ll let the authors decide whether this sentence is necessary.
>
> Regards,
> Alex
>
> On 11 May 2026, at 15:58, Kent Watsen <[e-mail]> wrote:
>
> 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
>
> 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]
>
>
>
>
> _______________________________________________
> netconf mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
>
>
> Mahesh Jethanandani
> [e-mail]
>
>
>
>
>
>
>
>
> Mahesh Jethanandani
> [e-mail]
>
>
>
>
>
>
>