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

[Kent Watsen <[e-mail]>]

Hi Thomas,


> On Dec 14, 2024, at 4:51 AM, [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