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

[[e-mail]]

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?

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.

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.

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.

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.

Best wishes
Thomas

From: Kent Watsen <[e-mail]>
Sent: Friday, December 13, 2024 4:36 PM
To: maqiufang (A) <maqiufang1=[e-mail]>
Cc: [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 Qiufang,


You are right that the -00 was published eight weeks ago, but it replaces draft-tao-netconf-data-export-capabilities-07 which was actually discussed years ago.

I see that in the Datatracker history, but it doesn’t change my comments, so much as raise questions regarding the reviews that occurred before.



I appreciate you point it out that it is the use of “server” and “client” that caused some confusion, maybe we should use “publisher” and “receiver” instead.

It would be helpful to use the terms published in RFC 8639.



But the transport-capabilities module augments the notification-capabilities module in RFC 9196 and is used to discover the capabilities for the publisher.

You have a point, but as has been said about other drafts recently, having many documents is difficult to reason about, and thus it is recommended to make each document as clear as possible on its own.



For example, before a configured subscription is installed, the subscriber needs to understand which transport protocols are supported by the publisher, as well as the available encodings for each transport protocol.

First, please note the word “subscriber” is confusing (to me) in the context of *configured* subscriptions (for dynamic subscriptions, the term “subscriber” is clear).  I think that, for configured subscriptions, it may be clearer to write “the NC/RC client configuring a subscription”.

Regarding your two points:

1)  For which transport protocols are supported by the publisher, isn’t this given from the server/publisher *implementing* a YANG module (e.g., https-notif or udp-notif)?

2) For which encodings are supported by the publisher for each transport protocol, isn’t this given by the server/publisher advertising support for the features (e.g., RFC 8639 defines the "encode-json” and “encode-xml” features)?   Oops, the 8639-features cannot indicate encodings per transport (e.g., the publisher may support only XML for https-notif, and only JSON for udp-notif).  What this indicates the me is that we’ve found yet another case where the RFC 8639 design is broken.


Yes, I understand the capability discovery in the https-notif focuses another case where encoding is unspecified in the subscription. But if both the receiver and publisher supports multiple encodings, I wonder how would the publisher select one from many?

The publisher likely has an ordered list of encoding preferences, and it picks the first match also supported by the receiver.



Finally it may still be unclear which encoding format will be used. I agree that it is easier if the encoding leaf could be defined as mandatory true, but I also understand sometimes a subscriber may just want to use a default one if there it is for a specific transport.

Congruent with intent-based automation, I agree that it is desirable for the (NC/RC) client to not have to care, leaving it to the system to determine, and so having the encoding leaf be "mandatory false” is goodness.

That said, it is a questionable benefit and, if udp-notif is unable to support an inline receiver-discovery mechanism, then it might be better to have “mandatory true", rather than the udp-notif draft having to pick a default (and mandatory to implement) encoding.

One thing that would help would be if the “encoding” leaf were a leafref to transport-specific supported-encoding in the “yp-transport-capabilities” data tree.  I continue to think that we should consider an rfc8639-bis that obsoletes RFC 8639.  Rob’s “YANG Push Lite” seems promising.


I will leave this to the authors of udp-notif, but my comments as a contributor is that, I think a lighter-weight way is to add some statements in the udp-notif draft that the receiver needs to understand that a publisher will select an encoding format itself when the “encoding” leaf is not configured; and if that default one is unwanted, it should configure the leaf with preferred encoding explicitly. That said, I realize that transport-capabilities module fails to identify a default encoding for a transport. I am wondering whether this should to be added in the next update.

Yes, the easiest fix, from a specification perspective, is for the udp-notif draft to pick a default (and mandatory to implement) encoding.


It’s just encoding capabilities for discovery, the final configuration of the encoding leaf must not go beyond the publisher’s capabilities to ensure a successful subscription.

Okay, finally I get it!  Sorry for being so slow understanding this draft’s purpose.  I think the reasons why are because:


  1.  I thought this draft addressed the concern I raised at IETF 120.
  2.  the email Alex sent <https://mailarchive.ietf.org/arch/msg/netconf/hSzXM6TJkk3TAAnMKl7ZSKyIBSk/> on October 17 further led me to believe my 120-comment was being addressed.
  3.  there was no on-list discussion between IETF 120 and IETF 121.
  4.  the IETF 121 presentation didn’t directly address my 120-concern, leaving me to still think that it did.
  5.  the draft was/is unclear with its use of terms and lack of clarifying statements.


PS: for those wondering, my 120-concern is still not addressed.

Kent / contributor