[netconf] Re: draft-ietf-netconf-http-client-server

[Mike Bishop <[e-mail]>]

Version negotiation happens using ALPN in TLS; that registry is at https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids. I had suggested the approach of carrying the list of ALPN tokens supported by the client/server, and Kent introduced me to IANA-maintained modules, which we discussed as a possible rendering of that.

The challenge with that idea was that, as this is a TLS registry, it would presumably be a separate document and completely reset the timeline. There are lots of registered tokens that are not HTTP, so it would seem odd for this draft to establish that module. It's also possible for a TLS implementation to negotiate a token that isn't in the registry, since it's ultimately just byte sequences; during H2 and H3 development, for example, it was common to present draft versions in ALPN. (This is the "solution that [involves] a separate document" I alluded to in my ballot.)
________________________________
From: Kent Watsen <[e-mail]>
Sent: Tuesday, June 3, 2025 11:27 AM
To: Rob Wilton (rwilton) <[e-mail]>; Mike Bishop <[e-mail]>
Cc: Mahesh Jethanandani <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [netconf] draft-ietf-netconf-http-client-server

Hi Rob (and Mike),

Thanks for chiming in.  Top-posting since my response is to the whole message.

Mike and I sat in the Bangkok hotel lobby for almost an hour near the end of the IETF 122 conference.  We discussed many things and, yes, the idea of a registry for HTTP versions came up.   Actually, Mike showed me an existing IANA registry that contained said values (amongst others), but I can't find it now.

Mike, which IANA registry is it that defines HTTP version string values?

Kent // author


On Jun 3, 2025, at 6:37 AM, Rob Wilton (rwilton) <[e-mail]> wrote:

Hi chairs, ADs,

Just reading Mike’s DISCUSS, and I had a quick suggestion as a potential compromise.

Did anyone discuss or consider putting the supported HTTP versions into an IANA registry (specific to YANG) and then have IANA derive a YANG module from it.  E.g., in case Mike isn’t that familiar with YANG, this would be similar to how the AFI IANA registry (https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml) automatically updates https://www.iana.org/assignments/iana-routing-types/iana-routing-types.xhtml if a new AFI is ever defined (as per the description for both of those registries).

That HTTP YANG versions registry could be marked as expert review (perhaps with assigned HTTP and YANG experts) which would allow new HTTP versions to be supported with a minimal registry update rather than requiring a new RFC to be published.

Just a thought/suggestion in case it may help unblock a roadblock …

Kind regards,
Rob