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

[[e-mail]]

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]<mailto:[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 fromhttps://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