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

[Kent Watsen <[e-mail]>]

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: 

I thought this draft addressed the concern I raised at IETF 120.
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.
there was no on-list discussion between IETF 120 and IETF 121.
the IETF 121 presentation didn’t directly address my 120-concern, leaving me to still think that it did.
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