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. 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. 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? 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 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 -- [email protected] > > To unsubscribe send an email to [email protected] > > _______________________________________________ > 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]
