> On 19 Mar 2021, at 04:42, Tommy Pauly <tpauly=40apple....@dmarc.ietf.org> > wrote: > > > >> 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. >> >> 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
It’s not so much is it in use or not. As I said this is a process issue. When the code point was assigned the way it was the wire and presentation formats are supposed to be *frozen* as that allows DNS developer to deploy code without having to worry about the specification changing underneath them. For BIND we haven’t shipped code with SVBC / HTTPS code points yet even to the point of parsing the records. We have merge request that has been tracking the draft. I never felt the specification was stable enough to do that and unfortunately I was correct. ALPN has had its parsing changed, the same presentation format produces different wire formats. echconfig vs ech is minor compared to that. I have not looked to see what other DNS vendors have done so far. If we go ahead there needs to be a section that specified the differences in parsing between the draft when the code point was issued and when the RFC is published. Mark >> --Ben >> >> On Wed, Mar 17, 2021 at 1:11 PM <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 [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/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/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 >> >> >> 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. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
