Hi Stephen, Thanks for the quick reply.
I think leaving it as Standards Action with a note that those actions are expected to update this RFC would be the easiest way forward. It might not be necessary, as it is likely that it would be caught during the processing of the RFC, but it might get it noticed earlier. If you do decide to loosen the registry policy instead, then I think the text around handling the keys would need to switch to something like this: The JSON file at the well-known URI MUST contain an object with two keys: "regeninterval", whose value is a number, and "endpoints" whose value is an array of objects. Any other keys must be registered as described in section 9, and implementations MUST ignore those keys which they do not understand. You could then update the procedure to specification required or expert review, with guidance to the expert that keys constraining the behavior of the mechanism will not be honored by older implementations. I don't have much of a sense of how likely it is that people will need new keys here, so I can't really give much of an opinion about which way forward is better. regards, Ted On Tue, Sep 2, 2025 at 8:30 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > Hi Ted, > > On 02/09/2025 15:40, Ted Hardie wrote: > > Hi Stephen, > > > > I have what I hope is a small question about the IANA registration. In > the > > protocol description, the draft says: > > > > The JSON file at the well-known URI MUST contain an object with two > > keys: "regeninterval", whose value is a number, and "endpoints" whose > > value is an array of objects. All other keys MUST be ignored. > > > > In the IANA considerations for the new JSON Service Binding registry, you > > specify Standards Action is required to update the registry. > > Ah. I think Standards Action was Ben's choice, or else, apologies to > Ben, and I just forget why we said that;-) > > > It seems to > > me that you actually need something a bit narrower, a Standards Action > that > > updates or obsoletes this RFC, since other actions wouldn't eliminate the > > "MUST be ignored." requirement. > > That's logical. > > > My IANAbis chair hat isn't on for this question, but it does cause me to > > think about what folks mean by Standards Action in a case like this; do > the > > authors assume Standards Action is sufficient, because that process would > > check to make sure that the new standard didn't need to make an update to > > this RFC? > > Yes, I would make that assumption, and it may be worth stating > in the document I guess? > > Or... we could consider "loosening" the registry update rule to > expert review with guidance to the expert that they should think > when adding things to that registry as the current setup means > they'll be ignored by existing implementations. (So, not much > point adding negative-things/constraints that need to be honoured > I guess.) > > I created a GH issue for this. [1] > > Thanks, > S. > > [1] https://github.com/sftcd/wkesni/issues/57 > > > > > Thanks, > > > > Ted Hardie > > > > > > On Tue, Sep 2, 2025 at 2:40 PM Stephen Farrell < > stephen.farr...@cs.tcd.ie> > > wrote: > > > >> > >> Hiya, > >> > >> We made a bunch of editorial changes after the comments > >> received at IETF-123 with which the commenters seem ok, > >> so the authors would like to ask if the chairs think this > >> is ready for WGLC. (We understand the plan is to park it > >> after that awaiting more implementation experience which > >> is fine.) > >> > >> There are no outstanding issues or PRs on the git repo. [1] > >> > >> Cheers, > >> S. > >> > >> [1] https://github.com/sftcd/wkesni > >> > >> On 02/09/2025 14:30, internet-dra...@ietf.org wrote: > >>> Internet-Draft draft-ietf-tls-wkech-09.txt is now available. It is a > >> work item > >>> of the Transport Layer Security (TLS) WG of the IETF. > >>> > >>> Title: A well-known URI for publishing service parameters > >>> Authors: Stephen Farrell > >>> Rich Salz > >>> Benjamin Schwartz > >>> Name: draft-ietf-tls-wkech-09.txt > >>> Pages: 18 > >>> Dates: 2025-09-02 > >>> > >>> Abstract: > >>> > >>> We define a well-known URI at which an HTTP origin can inform an > >>> authoritative DNS server, or other interested parties, about its > >>> Service Bindings. Service binding data can include Encrypted > >>> ClientHello (ECH) configurations, that may change frequently. > This > >>> allows the origin, in collaboration with DNS infrastructure > elements, > >>> to publish and rotate its own ECH keys. Other service bindng data > >>> such as information about TLS supported groups is unlikely to > change > >>> quickly, but the origin is much more likely to have accurate > >>> information when changes do occur. Service data published via > this > >>> mechanism is typically available via an HTTPS or SVCB resource > >>> record. > >>> > >>> The IETF datatracker status page for this Internet-Draft is: > >>> https://datatracker.ietf.org/doc/draft-ietf-tls-wkech/ > >>> > >>> There is also an HTMLized version available at: > >>> https://datatracker.ietf.org/doc/html/draft-ietf-tls-wkech-09 > >>> > >>> A diff from the previous version is available at: > >>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-wkech-09 > >>> > >>> Internet-Drafts are also available by rsync at: > >>> rsync.ietf.org::internet-drafts > >>> > >>> > >>> _______________________________________________ > >>> TLS mailing list -- tls@ietf.org > >>> To unsubscribe send an email to tls-le...@ietf.org > >> > >> _______________________________________________ > >> TLS mailing list -- tls@ietf.org > >> To unsubscribe send an email to tls-le...@ietf.org > >> > > > >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
