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

I don't think it's impossible for the HTTP WG to maintain that registry — it seems fairly low-maintenance, and a future version of HTTP could easily throw an entry in its IANA Considerations to do so. "Interest" is probably overstating things, but willingness might exist.

Going to Med's comment about the text in 8407bis, however, I note that https://www.ietf.org/archive/id/draft-ietf-netmod-rfc8407bis-28.html#name-context seems fairly explicit that we shouldn't create parallels to things which already exist. I'm also a little non-plussed about putting notes on TLS's registry for HTTP/YANG purposes, though I suspect we don't actually need that note. If we created a parallel registry for YANG purposes, we'd just update it as needed.

Maybe let's separate timeline for a moment. If we didn't care about resetting the schedule for these documents, would we prefer to use the ALPN registry or create a separate registry of HTTP versions? (And mostly for my education, does YANG support having something that is either an enum from the registry or a bytestring, since it's possible to use unregistered ALPN values?) Given that the registry already exists, I suspect there are ways to fast-track the process of asking IANA to expose it in a new format.

There's another related issue from the ballot, which I noted around the proxy configuration. The client side of this draft combines two things: configuration of an HTTP client which might be able to access multiple services and describing a particular HTTP server endpoint to a client. (I noted that proxy configuration is generally a property of the client, not a property of the endpoint it's trying to reach.) It seems to me that turning on/off protocol support on the client and describing what a client should expect the service to support are slightly different things, with different expected behaviors on the client.

________________________________
From: Kent Watsen <kent+ietf@watsen.net>
Sent: Friday, June 6, 2025 10:51 AM
To: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
Cc: Rob Wilton (rwilton) <rwilton@cisco.com>; Mike Bishop <mbishop@evequefou.be>; netconf@ietf.org <netconf@ietf.org>
Subject: Re: [netconf] draft-ietf-netconf-http-client-server


So the maintenance moves from:


  *   write an RFC to update a YANG module

to:


  *   write an RFC to update a registry so IANA can update a YANG module


This is only better if:


  1.  the registry is updated/maintained by the ___domain owners
  2.  the registry serves a purpose beyond supporting a single YANG module

Note that this was/is my question to Mike regarding HTTPBIS WG's interest, to which he has yet to reply.


To Rob's point about the ALPN registry potentially not being a longterm source of truth, I'll concede that it is possible, given the HTTP protocol's propensity to swap out its transport between versions, but this is not concerning as the IANA notes for how/when to update the YANG module can be adjusted at that time.


Kent // contributor


On Jun 5, 2025, at 2:19 PM, mohamed.boucadair@orange.com wrote:

Re-,

+1 to all what Rob said.

Cheers,
Med

De : Rob Wilton (rwilton) <rwilton@cisco.com>
Envoyé : jeudi 5 juin 2025 18:46
À : Kent Watsen <kent+ietf@watsen.net>; Mike Bishop <mbishop@evequefou.be>
Cc : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>; netconf@ietf.org
Objet : Re: [netconf] draft-ietf-netconf-http-client-server




Hi Kent,

Regarding option 2.

I’m not proposing that we do anything to the ALPN registry at all, since this is really about HTTP version codes rather than anything to do with TLS or ALPN codes.

It is just an entirely separate/independent registry of HTTP versions used in the YANG modules.  This draft would define this new YANG/HTTP version registry.  When a new version of HTTP comes out then anyone can ask for a new entry to be added to the registry, expert reviewers (prob one with HTTP expertise and one with YANG expertise) review/approve the change, and then IANA generates the updated YANG module when the registry gets updated.

Basically, I think that we want to avoid tying this to ALPN since there are many other sequences in the ALPN registry beyond just HTTP, and I don’t think that it is necessarily guaranteed that all future versions of HTTP would always be added to the ALPN registry (although that is seemingly very likely).  I.e., it is the decoupling and clean separation that makes this approach preferable to me.

Kind regards,
Rob



From: Kent Watsen <kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>>
Date: Thursday, 5 June 2025 at 17:20
To: Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>
Cc: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>, Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>, netconf@ietf.org<mailto:netconf@ietf.org> <netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: Re: [netconf] draft-ietf-netconf-http-client-server


We seem to be spinning on two options:

Option 1: (my pref)

o    Add a note to the ALPN registry to consider if a new HTTP version has been defined and, if so, auto-update (with expert review) some new iana-http-versions YANG module

Option 2: (Rob/Med's pref, I think)

o    Add a note to the ALPN registry to consider if a new HTTP version has been defined and, if so, auto-update (with expert review) some new "HTTP Versions" registry and then auto-update ( (with no expert review) some new iana-http-versions YANG module.

o    FWIW, an optional path exists, which is for future HTTP RFCs to explicitly update the "HTTP Versions" registry, in addition to the ALPN registry, negating the need for a note in the ALPN registry.

I don't see Option 2 as being better than Option 1, since Option 2 adds an unnecessary step (to updating an iana-http-versions YANG module, which is all we care about), unless there is some broader interest in there being a dedicated "HTTP Versions" registry.


Mike:

Would the HTTPBIS WG be interested in a dedicated "HTTP Versions" registry, perhaps something like the below?

Version Reference
HTTP/0.9 [RFC1945]
HTTP/1.0 [RFC1945]
HTTP/1.1 [RFC9112]
HTTP/2 [RFC9113]
HTTP/3 [RFC9114]


Kent // author





On Jun 5, 2025, at 10:23 AM, Rob Wilton (rwilton) <rwilton=40cisco.com@dmarc.ietf.org<mailto:rwilton=40cisco.com@dmarc.ietf.org>> wrote:

Hi Med,

Ah, okay.  I’m also happy for it to be setup as a regular registry and for the YANG module to be automatically derived from that, as proposed previously.

I suspect the key is whether this approach would be acceptable to Mike & Kent?

Kind regards,
Rob



From: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Date: Thursday, 5 June 2025 at 13:40
To: Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>, Kent Watsen <kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>>
Cc: Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>, netconf@ietf.org<mailto:netconf@ietf.org> <netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: RE: [netconf] draft-ietf-netconf-http-client-server

Hi Rob,

Fully agree on your first point.

For the second one, YANG is no more than another presentation format of a registry :-). We clarified this in 8407bis:

   IANA maintains a set of registries that are key for interoperability.
   The content of these registries are usually available using various
   formats (e.g., plain text, XML).  However, there were some confusion
   in the past about whether the content of some registries is dependent
   on a specific representation format.
   …
   guidelines are meant to leverage existing IANA registries and use
   YANG as another format to present the content of these registries
   when appropriate.

Cheers,
Med (as contributor)

De : Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>
Envoyé : jeudi 5 juin 2025 12:18
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>; Kent Watsen <kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>>
Cc : Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>; netconf@ietf.org<mailto:netconf@ietf.org>
Objet : Re: [netconf] draft-ietf-netconf-http-client-server




Hi all,

I still feel that what I propose is a bit cleaner.  I.e., it is very clear what the purpose of the registry is, i.e., the versions of HTTP that are supported via the http client server models.

Another choice could be to ask IANA if they would maintain a simple enum YANG module without needing the associated registry at all?  However, I’m not sure that they do this today, so this could be something new.

Kind regards,
Rob



From: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com><mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Date: Thursday, 5 June 2025 at 10:17
To: Kent Watsen <kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>>
Cc: Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>, Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>, netconf@ietf.org<mailto:netconf@ietf.org> <netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: RE: [netconf] draft-ietf-netconf-http-client-server

Hi Kent,

There will be one step/hop for both options and both will require a DE. Also, I don’t expect the changes to be that frequent.

I said “a slight preference” mainly because this won’t disturb the rules already in place for the ALPN registry.

Cheers,
Med (as contributor)

De : Kent Watsen <kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>>
Envoyé : mercredi 4 juin 2025 18:26
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>
Cc : Rob Wilton (rwilton) <rwilton=40cisco.com@dmarc.ietf.org<mailto:rwilton=40cisco.com@dmarc.ietf.org>>; Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>; netconf@ietf.org<mailto:netconf@ietf.org>
Objet : Re: [netconf] draft-ietf-netconf-http-client-server



Hi Med,

That RFC appears to define new source-of-truth registries, meaning that the [D]TLS version numbers are not defined by any other existing IANA registry.



But here there exists an existing source-of-truth registry, the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry.   Why not use the existing source-of-truth registry and avoid the extra hop?



Kent // contributor




On Jun 4, 2025, at 10:25 AM, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>wrote:

Hi Kent, all,

I think that I have a slight preference for Rob’s approach for the simple raison that we already exercised that same path for TLS/DTLS inhttps://datatracker.ietf.org/doc/html/rfc9761#name-acl-tls-version-registry.


Cheers,
Med (as contributor)

De : Kent Watsen <kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>>
Envoyé : mercredi 4 juin 2025 16:13
À : Rob Wilton (rwilton) <rwilton=40cisco.com@dmarc.ietf.org<mailto:rwilton=40cisco.com@dmarc.ietf.org>>
Cc : Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>; netconf@ietf.org<mailto:netconf@ietf.org>
Objet : [netconf] Re: draft-ietf-netconf-http-client-server





I was envisioning something even simpler than Rob's suggestion.  That is, to scrap the existing "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry, but only cherry-pick out the HTTP-related ALPNs.  No script to automate this is needed, just an expert-review comment saying, if this registery adds an HTTP-related ALPN, IANA should auto-update the IANA-maintained YANG module.  Thoughts?

Kent




On Jun 4, 2025, at 6:19 AM, Rob Wilton (rwilton) <rwilton=40cisco.com@dmarc.ietf.org<mailto:rwilton=40cisco.com@dmarc.ietf.org>> wrote:

Hi Mike,

Thanks for the explanation.  My alternative suggestion is slightly simpler.

My proposal is that this document (draft-ietf-netconf-http-client-server ) defines a new registry of HTTP versions that are supported by the draft-ietf-netconf-http-client-server YANG model, and the IANA module is derived from this new registry.  So, it would be a YANG specific HTTP registry rather than a generic one.  Hence, this document could define that registry and the process for generating the IANA file from it, and no separate document would be needed.  New HTTP versions could be supported (presuming that there are no other changes required to the YANG module), simply by someone updating the registry with the new version, which would cause a new version of the YANG module to automatically be generated.  There is no reason why that process couldn’t be achieved in a couple of weeks rather than a standard IETF publication cycle.

The downside of this approach is putting the HTTP version numbers in another registry, but arguably this is little different that baking them directly into a YANG file as an enumeration.  Perhaps this is a potential acceptable compromise to get this doc unblocked.

I know that you have suggested that a client shouldn’t have to know or care what HTTP version is being used, but I think that there are deployment scenarios where the same organizational entity is in control of both client and server (e.g., both controller and all the network devices being controlled), and constraining the versions reduces complexity and potential attack surface area.  E.g., if I know that my clients and all network devices support H3 then constraining them to only make H3 or later connections would seem to avoid any potential downgrade attacks?

Kind regards,
Rob



From: Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>
Date: Tuesday, 3 June 2025 at 20:39
To: Kent Watsen <kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>>, Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>,netconf@ietf.org<mailto:netconf@ietf.org> <netconf@ietf.org<mailto:netconf@ietf.org>>
Subject: Re: [netconf] draft-ietf-netconf-http-client-server

Version negotiation happens using ALPN in TLS; that registry is athttps://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 <kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>>
Sent: Tuesday, June 3, 2025 11:27 AM
To: Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>; Mike Bishop <mbishop@evequefou.be<mailto:mbishop@evequefou.be>>
Cc: Mahesh Jethanandani <mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>; netconf@ietf.org<mailto:netconf@ietf.org><netconf@ietf.org<mailto:netconf@ietf.org>>
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) <rwilton@cisco.com<mailto:rwilton@cisco.com>> 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

_______________________________________________
netconf mailing list -- netconf@ietf.org<mailto:netconf@ietf.org>
To unsubscribe send an email to netconf-leave@ietf.org<mailto:netconf-leave@ietf.org>


____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_______________________________________________
netconf mailing list -- netconf@ietf.org<mailto:netconf@ietf.org>
To unsubscribe send an email to netconf-leave@ietf.org<mailto:netconf-leave@ietf.org>


____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.

_______________________________________________
netconf mailing list -- netconf@ietf.org<mailto:netconf@ietf.org>
To unsubscribe send an email to netconf-leave@ietf.org<mailto:netconf-leave@ietf.org>


____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
netconf mailing list -- netconf@ietf.org<mailto:netconf@ietf.org>
To unsubscribe send an email to netconf-leave@ietf.org<mailto:netconf-leave@ietf.org>