[netconf] Re: [NMOP] New Version Notification for draft-netana-netconf-yp-transport-capabilities-00.txt

[Andy Bierman <[e-mail]>]

On Thu, Jan 23, 2025 at 12:48 PM Kent Watsen <[e-mail]> wrote:

> IMO, 8639 is DotW (dead in the water).  Let it go.  It doesn’t matter
> because no one it using it.
>
>

RFC 8639 is in use by some vendors.
YANG Push uses it. UDP-Notif uses it.
Even without YANG Push it is a major improvement over RFC 5277
subscriptions.

We are close to releasing full XML, JSON, and CBOR support for dynamic
subscriptions over NETCONF
and configured subscriptions over UDP-Notif. The recent improvements add to
the RFC 8639 module
instead of replacing it.

Why is a mandatory encoding required for UDP-Notif when it is not for
RESTCONF?



> So either #3 or #4.
>
> K.
>
>

Andy


>
> On Jan 23, 2025, at 3:25 PM, Kent Watsen <[e-mail]> wrote:
>
> Hi Thomas,
>
> This is a conflicted matter.
>
> I go with #4, because I don’t believe there are any existing deployments
>
> K.
>
>
> Kent // as chair
>
> On Dec 20, 2024, at 5:03 AM, [e-mail] wrote:
>
> Hi Kent,
>
> Thanks for confirming.
>
> The mandatory encoding question has been raised at the IETF 107,
> https://mailarchive.ietf.org/arch/msg/netconf/5cb91SD7wfrgdei4wBailQSG6xQ/
> , https://www.surveymonkey.com/r/68W3DX3. The choices did not include
> CBOR. The working group decided to let market decide in contrary to
> https://datatracker.ietf.org/doc/html/rfc8639#section-7 which lead to
> https://www.rfc-editor.org/errata/eid6211.
>
> From there, to my knowledge, the NETCONF working group has now 4
> possibilities:
>
>
>    1. To *mandate default encoding* for all YANG-Push transport protocols
>    (https-notif and udp-notif) until a new document (possibly
>    draft-wilton-netconf-yp-observability) updates RFC 8639 with errata eid6211
>    which gives the implementor the choice of implementing any discovery
>    mechanism or a default encoding.
>    2. To *mandate default encoding* for all YANG-Push transport protocols
>    (https-notif and udp-notif) until a new document (possibly
>    draft-wilton-netconf-yp-observability) updates RFC 8639 with a requirement
>    of draft-netana-netconf-yp-transport-capabilities based on RFC 9196.
>    3. To *ignore default encoding requirements* for all YANG-Push
>    transport protocols (https-notif and udp-notif) until a new document
>    (possibly draft-wilton-netconf-yp-observability) updates RFC 8639 with
>    errata eid6211 which gives the implementor the choice of implementing any
>    discovery mechanism or a default encoding.
>    4. To *ignore default encoding requirements* for all YANG-Push
>    transport protocols (https-notif and udp-notif) until a new document
>    (possibly draft-wilton-netconf-yp-observability) updates RFC 8639 with a
>    requirement of draft-netana-netconf-yp-transport-capabilities based on RFC
>    9196.
>
>
>
> Regarding
>
> > That draft is related, but neither defines a default encoding nor
> provides a mechanism for the publisher to discover the collector’s
> capabilities.
>
> https://datatracker.ietf.org/doc/html/rfc9196
>
> The module "ietf-system-capabilities" provides a placeholder structure
> that can be used to discover YANG-related system capabilities for servers.
>
> Correct. RFC 9196 covers the publisher and not the collectors
> capabilities. I remind NETCONF working group had already a lengthy thread
> https://mailarchive.ietf.org/arch/msg/netconf/ozmoIPImyiZ2k5V4I-LfwUaliFE/
>  in 2021 on this discussion. That lead to the working group consensus of
> covering the publisher in RFC 9196. RFC 8639 and RFC 8641 don't mandate
> that transport capabilities are discoverable. See above.
>
> I hope this summary helps to understand the current state. Please
> comment/correct and lets avoid being caught in a time loop,
> https://en.wikipedia.org/wiki/Groundhog_Day_(film).
>
> From a network operator and YANG-Push receiver, Network Telemetry (RFC
> 9232) data collection, perspective here my comments/suggestions:
>
> Follow the NETCONF working group consensus of deciding the market which
> encodings (JSON, XML, CBOR named identifiers, CBOR SID) should be
> implemented. With MVP 1 and 2 (slide 12
> https://datatracker.ietf.org/meeting/121/materials/slides-121-nmop-ietf-yang-push-implementations-and-next-steps-01.pdf)
> we have an alignment from multiple implementors and operators to start with
> JSON in MVP 1 and CBOR named identifiers in MVP 2. That is to me a sensible
> approach.
>
> Define one single mechanism of discovering the YANG-Push publisher
> capabilities as defined in RFC 9196. Covering transport
> protocol/encoding/security
> (draft-netana-netconf-yp-transport-capabilities), notification header type
> and extension (
> https://datatracker.ietf.org/doc/html/draft-netana-netconf-notif-envelope-01#section-3.2)
> and subscription capabilities (on-change, periodical, interval,
> https://datatracker.ietf.org/doc/html/rfc9196#section-3) Multiple
> mechanisms leads to overhead in implementations and therefore in a slow
> down of adoption of the solution. Therefore it should be avoided.
>
> When defining a mechanism for data collection capabilities, it should be
> Network Telemetry protocol agnostic and covering transport, notification,
> subscription, transformation and aggregation capabilities
> (NEW-OPS-REQ-REUSABILITY).
>
> Best wishes
> Thomas
>
> *From:* Kent Watsen <[e-mail]>
> *Sent:* Thursday, December 19, 2024 5:43 PM
> *To:* Graf Thomas, INI-NET-VNC-HCS <[e-mail]>
> *Cc:* maqiufang (A) <maqiufang1=[e-mail]>;
> [e-mail];
> [e-mail];
> [e-mail]
> *Subject:* Re: [netconf] New Version Notification for
> draft-netana-netconf-yp-transport-capabilities-00.txt
>
> *Be aware:* This is an external email.
>
> Hi Thomas,
>
>
>
> On Dec 14, 2024, at 4:51 AM, [e-mail] wrote:
>
> Dear Kent, Qiufang, NETCONF working group
>
> I summarize to ensure that I understood the conversation correctly.
>
> Kent as an individual requests that RFC 8639 based transport protocols
> require a default encoding to fulfill
> https://datatracker.ietf.org/doc/html/rfc8639#section-7 requirements.
> Therefore draft-netana-netconf-yp-transport-capabilities doesn't address
> his concerns.
>
> Correct?
>
>
> The last sentence is correct.
>
>
>
> I try to give context, please correct me if I miss or misinterpret
> anything.
>
> RFC 8639 states that a default encoding is needed.
>
> https://datatracker.ietf.org/doc/html/rfc8639#section-7
>
>    A specification for a transport MUST identify any encodings that are
>    supported.  If a configured subscription's transport allows different
>    encodings, the specification MUST identify the default encoding.
>
> In the transport example this is not exampled
>
> https://datatracker.ietf.org/doc/html/rfc8639#appendix-A
>
>
> Kent as netconf chair raised on 2020-06-22 the point of adding the point of discoverability in the errata
>
> https://www.rfc-editor.org/errata/eid6211
> https://mailarchive.ietf.org/arch/msg/netconf/KADgtx1UZBJPtr-AITD1Pgn50J0/
>
> based on
>
> https://mailarchive.ietf.org/arch/msg/netconf/XBpoFqtRynfc0zaRggMEiEMBW2M/
>
> proposing
>
>    A specification for a transport MUST identify any encodings that are
>    supported.  If a configured subscription's transport allows different
>    encodings, the specification MUST identify the default encoding, or
>    provide a mechanism whereby supported encodings can be discovered.
>
> Errata 6211 has status "Held for Document Update" which means it shall be
> considered a future
> update of the document. Thanks Rob for the pointer to
> https://www.rfc-editor.org/errata-definitions/.
>
>
>
> https://datatracker.ietf.org/doc/html/draft-netana-netconf-yp-transport-capabilities
>  is addressing this point based on RFC 9196 defined work.
>
>
> That draft is related, but neither defines a default encoding nor provides
> a mechanism for the publisher to discover the collector’s capabilities.
>
>
>
> To my knowledge, the reason why "or provide a mechanism whereby supported
> encodings can be discovered" wasn't added in RFC 8639 was because
> draft-ietf-netconf-notification-capabilities (RFC 9196) was still in
> netconf working group adopted state.
>
>
> Likely more related to no one implementing RFC 8639 before it was
> published.
>
>
>
> That implies that transport protocols implemented for RFC 8639 require
> default encoding. That applies to https-notif (
> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-https-notif-15#section-6.2)
> and udp-notif (
> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#section-7.1)
> Both have identities which do not default to an encoding.
>
>
> I suppose, to the letter, yes.  IDK why Rob selected "Held for Document
> Update”.
>
>
>
> However, we have from
> https://mailarchive.ietf.org/arch/msg/netconf/XBpoFqtRynfc0zaRggMEiEMBW2M/
>  the netconf working group the decision
>
> As reported before, 70% picked "Let the market decide”, with the remaining
> 30% all picking "Publisher MUST implement JSON encoding”.
>
> We arrive here now at a catch-22 (
> https://en.wikipedia.org/wiki/Catch-22_(logic))
>
> Before going into proposals, lets stop for a moment and see wherever we
> are all on the same page. Thanks.
>
>
>
> Sounds right to me.  Thanks for finding all the references.
>
> Kent
>
>
> --
> Nmop 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]
>