> On Mar 17, 2021, at 6:04 PM, Ben Schwartz > <bemasc=40google....@dmarc.ietf.org> wrote: > > Release notes for this revision: > * Simplify the IANA instructions (pure First Come First Served) > * Recommend against publishing chains of >8 aliases > * Clarify requirements for using SVCB with a transport proxy > * Adjust guidance for Port Prefix Naming > * Minor editorial updates > > I'm only aware of one outstanding issue: a proposal to change the name of the > "echconfig" key to "ech". This key corresponds to a value that is an > "ECHConfigList", which is a collection of "ECHConfig" structs, and some > implementers have reported that the singular/plural name-value mismatch > created confusion. This issue is discussed in detail here: > https://github.com/MikeBishop/dns-alt-svc/pull/299 > <https://github.com/MikeBishop/dns-alt-svc/pull/299>. > > This name has no effect on queries, responses, or zone transfers, but it does > appear in zone files. Zone files will not be portable between > implementations that use different names. This is true whether we "burn" the > current codepoint and allocate a new one, or simply rename the current > codepoint. However, using a new codepoint would allow updated > implementations to support both names, facilitating zone file portability in > one direction. It would also be possible to support the old name with > special-case name aliasing logic. > > In my view, the temporary portability benefit is too small to justify the > permanent registry pollution of a deprecated codepoint, especially because > ECH itself is not yet finalized, and there are no deployments except for > standards development purposes. However, others have disagreed. We'll need > to reach consensus before making any changes here.
Personally, I’d prefer to see the name change, and not burn a codepoint, as long as we’re not breaking any zone files. I think the question is: does anyone have a zone that has actually deployed the echconfig parameter? I see many responses with SVCB/HTTPS records, but none with the echconfig in practice. If someone is aware of a production deployment that can’t move, please speak up! Tommy > > --Ben > > On Wed, Mar 17, 2021 at 1:11 PM <internet-dra...@ietf.org > <mailto:internet-dra...@ietf.org>> wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : Service binding and parameter specification via the > DNS (DNS SVCB and HTTPS RRs) > Authors : Ben Schwartz > Mike Bishop > Erik Nygren > Filename : draft-ietf-dnsop-svcb-https-04.txt > Pages : 48 > Date : 2021-03-17 > > Abstract: > This document specifies the "SVCB" and "HTTPS" DNS resource record > (RR) types to facilitate the lookup of information needed to make > connections to network services, such as for HTTPS origins. SVCB > records allow a service to be provided from multiple alternative > endpoints, each with associated parameters (such as transport > protocol configuration and keys for encrypting the TLS ClientHello). > They also enable aliasing of apex domains, which is not possible with > CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP > origins. By providing more information to the client before it > attempts to establish a connection, these records offer potential > benefits to both performance and privacy. > > TO BE REMOVED: This document is being collaborated on in Github at: > https://github.com/MikeBishop/dns-alt-svc > <https://github.com/MikeBishop/dns-alt-svc> [1]. The most recent > working version of the document, open issues, etc. should all be > available there. The authors (gratefully) accept pull requests. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ > <https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/> > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-04 > <https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-04> > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-04 > <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-04> > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-04 > <https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-04> > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org > <http://tools.ietf.org/>. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/> > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org <mailto:DNSOP@ietf.org> > https://www.ietf.org/mailman/listinfo/dnsop > <https://www.ietf.org/mailman/listinfo/dnsop> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
