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

[Siddharth Bhat <[e-mail]>]

Hi all,

Apologies for the delayed reply!

Thanks for the discussion and for updating draft-ietf-netconf-https-notif
to -16. We agree with the sentiment that ietf-netconf-https-notif is
explicitly meant for YANG notifications, and that legacy RFC 5277
notifications can be handled separately when advertised as a capability.

We have updated draft-ietf-netconf-https-notif-cbor(
https://datatracker.ietf.org/doc/draft-ietf-netconf-https-notif-cbor/01/ )
accordingly:
1. Adopted Option 1: application/cbor is replaced with
application/yang-data+cbor throughout, with id=name or id=sid used to
indicate name-based vs SID-based encoding.
2. Capability URNs in all examples have been updated to the new format
(urn:ietf:params:yang-notif:https-capability:encoding:cbor)
3. Added some additional details and clarifications into the draft, and
made some editorial changes.

We plan to present the updated draft at IETF 126.

Thanks,
Meher, Siddharth, Vartika, Hayyan

On Sat, Jul 4, 2026 at 1:19 AM 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]
>
>
>
>
>
>
>

-- 
Siddharth Bhat
[e-mail]