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 <[email protected]> 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, [email protected] wrote:Internet-Draft draft-ietf-tls-wkech-09.txt is now available. It is awork itemof 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 -- [email protected] To unsubscribe send an email to [email protected]_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
