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

[Kent Watsen <[e-mail]>]

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.

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.

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.

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?).

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? 

Kent / contributor



> On Oct 17, 2024, at 9:15 AM, [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