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

["maqiufang (A)" <[e-mail]>]

Hi, Kent,

Thanks for bringing this up, I’ve shared some of my thoughts below inline, my co-authors may want to clarify more if they’d like.

From: Kent Watsen [mailto:[e-mail]]
Sent: Friday, December 13, 2024 12:31 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [netconf] New Version Notification for draft-netana-netconf-yp-transport-capabilities-00.txt


Transport Capabilities authors,

It is unfortunate to note that this I-D has had no discussion on list since the -00 was published eight weeks ago.  This draft was presented at IETF 121 (minutes<https://datatracker.ietf.org/meeting/121/materials/minutes-121-netconf-202411081300-01>) with a request for more on list discussion.
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.
During the 121 presentation, I expressed some confusion around what the draft was trying to achieve.  I’ve since read the draft and slides again, and admit that I’m still confused.  Much of my confusion is due to use of terms like “client” and “server”, when there are two sets of each.  A component diagram and matching sequence diagram would help.  A statement somewhere (perhaps in the udp-notif draft) like “the collector does not have to be a ’server’, e.g., a NETCONF server or a RESTCONF server” would help further clarify the document.
I recalled I heard your comments at IETF 121 and I was confused by your confusion, but now I see where you came from;-)
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. But the transport-capabilities module augments the notification-capabilities module in RFC 9196 and is used to discover the capabilities for the publisher. 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.

To help this discussion some, the https-notif draft’s capabilities mechanism was defined to be used when the “encoding” leaf described in https://www.rfc-editor.org/rfc/rfc8639.html#section-3.3 is not configured, as it is “mandatory false”.  As an aside, I think RFC 8639 should’ve made the “encoding” leaf be "mandatory true”, and I wonder if an rfc8639-bis might be easier.  There’s the description statement for the “encoding" leaf:

The “description” for the “encoding” leaf is:

      description
        "The type of encoding for notification messages.  For a
         dynamic subscription, if not included as part of an
         'establish-subscription' RPC, the encoding will be populated
         with the encoding used by that RPC.  For a configured
         subscription, if not explicitly configured, the encoding
         will be the default encoding for an underlying transport.";

The end of the last sentence says "the default encoding for an underlying transport”.  But the https-notif draft (as well as the udp-notif draft) doesn’t want to specify a “default encoding”, just like why RESTCONF (RFC 8040) doesn’t specify a default encoding.  So the https-hotif draft defined an ability for the publisher to query the collector to obtain a list of media-types (e.g., application/yang-data+json) the collector supports.  Then the publisher selects one and starts pushing messages to the server using that encoding.
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? 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.

This is the kind of capabilities discovery mechanism I thought was missing in the udp-notif draft.  That said, IDK how it would be possible with UDP for the collector to send its list of supported encodings to the publisher (e.g., what port?).
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.

Note the following statement in the section 7 of RFC 8639:
   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.

When reading the transport-capabilities draft, what I see (I think) is an alternate way for the “encoding” leaf to be configured, on the publisher.  But, if true, why not just configure the encoding leaf directly?
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.
Kent / contributor

Best Regards,
Qiufang


On Oct 17, 2024, at 9:15 AM, [e-mail]<mailto:[e-mail]> wrote:

Dear Netconf,

We published a new document extending RFC 9196 system capabilities to discover YANG-Push transport, encoding and security related capabilities. Making draft-ietf-netconf-udp-notif  and draft-ietf-netconf-https-notif transport discoverable as described in https://datatracker.ietf.org/doc/html/rfc8639#section-7 resp. https://www.rfc-editor.org/errata/eid6211. The document replaces and updates draft-tao-netconf-data-export-capabilities which was previously discussed at netconf.

We are looking forward to get comments and feedback.

Best wishes
Thomas