- From: Mark Andrews <marka@isc.org>
- Date: Wed, 24 Jun 2020 09:38:14 +1000
- To: Tommy Pauly <tpauly@apple.com>
- Cc: Martin Thomson <mt@lowentropy.net>, ietf-http-wg@w3.org
One doesn’t need an early allocation for interop testing. Just pick 2 private type values. BIND uses SVBC/65481 and HTTPS/65482 which matches what dnspython is doing for their testing. If the record format changes pick 2 new private values and discard the old ones. Use “TBA (use 65XXXX for pre allocation testing)” in the draft so everyone is in sync with a particular WIRE FORMAT. The final allocation can be made by IANA when the document is with the RFC editor. I’ve done this a number of times with multiple RR types. > On 24 Jun 2020, at 00:29, Tommy Pauly <tpauly@apple.com> wrote: > > Thanks for filing issues on the GitHub, Martin! > > Regarding the done-ness and implementations, I agree that this certainly isn’t as mature as QUIC. The key thing at this time is getting the wire format stable enough to do the RR type early allocation, which will enable broader interop and deployment testing. Seeing implementations ship prior to publishing the RFC here is an important step, as you indicate. > > Tommy > >> On Jun 23, 2020, at 2:25 AM, Martin Thomson <mt@lowentropy.net> wrote: >> >> Hi Erik, >> >> Thanks for passing this along. I think that this is - as you say - almost done, but not perhaps in the same way that QUIC is almost done. It's pretty good for a -00 draft, but I found a fairly large number of issues in my review. Those were mostly editorial or quite minor, but it suggests that maybe another round of edits would be good. >> >> I don't quite see the same decoupling from Alt-Svc that I was expecting based on your note. I think that the balance there is about right, but I would frame this as a parallel mechanism to Alt-Svc that is deliberately compatible. >> >> As for implementation, we have plans to implement as a client. They are not concrete plans, however, so don't ask about dates. I expect that more feedback will be forthcoming as that happens; if you believe that this can ship before then, then I would hope that you would be able to get some experience with client implementations in lieu of what we can provide. >> >> I also think that the requirements for recursive resolvers are such that experience with implementation there is similarly necessary. >> >> On Thu, Jun 18, 2020, at 12:48, Erik Nygren wrote: >>> We're hoping to start WGLC in DNSOP sometime in the next month or two >>> for the HTTPS RR type (formerly "HTTPSSVC", along with SVCB). >>> We submitted an early code point allocation request for the DNS RR types. >>> As such, now would be a good time to take another read through. >>> >>> Remaining issues are tracked here (and can be discussed here, >>> in dnsop, or in the issue tracker as appropriate): >>> >>> https://github.com/MikeBishop/dns-alt-svc/issues >>> >>> The most relevant to the HTTP WG are: >>> >>> * Consider SVCB-Used header >>> <https://github.com/MikeBishop/dns-alt-svc/issues/107> >>> * Parameter to indicate no HSTS-like behavior >>> <https://github.com/MikeBishop/dns-alt-svc/issues/100> >>> * Consider a way to indicate some keys as "mandatory" >>> <https://github.com/MikeBishop/dns-alt-svc/issues/166> >>> >>> Note that the current draft decouples itself fully from Alt-Svc. >>> That there are a few areas for future improvement to Alt-Svc >>> that came out of discussion here, but are not covered in the current draft. >>> >>> The latest authors' draft (for pull requests) is at: >>> >>> https://github.com/MikeBishop/dns-alt-svc/blob/master/draft-ietf-dnsop-svcb-https.md >>> >>> and latest published is at: >>> >>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-00 >>> >>> Best, Erik >>> >>> >>> ---------- Forwarded message --------- >>> From: <internet-drafts@ietf.org> >>> Date: Fri, Jun 12, 2020 at 4:18 PM >>> Subject: New Version Notification for draft-ietf-dnsop-svcb-https-00.txt >>> To: Benjamin Schwartz <bemasc@google.com>, Erik Nygren >>> <erik+ietf@nygren.org <mailto:erik%2Bietf@nygren.org>>, Mike Bishop >>> <mbishop@evequefou.be> >>> >>> >>> >>> A new version of I-D, draft-ietf-dnsop-svcb-https-00.txt >>> has been successfully submitted by Ben Schwartz and posted to the >>> IETF repository. >>> >>> Name: draft-ietf-dnsop-svcb-https >>> Revision: 00 >>> Title: Service binding and parameter specification via the DNS (DNS >>> SVCB and HTTPS RRs) >>> Document date: 2020-06-12 >>> Group: dnsop >>> Pages: 39 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-ietf-dnsop-svcb-https-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ >>> Htmlized: https://tools.ietf.org/html/draft-ietf-dnsop- >>> <https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-00>svcb-https-00 <https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-00> >>> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-s >>> <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https>Consider a "mandatory" key range <https://github.com/MikeBishop/dns-alt-svc/issues/166>s <https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-00>vcb-https <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https> >>> >>> >>> Abstract: >>> This document specifies the "SVCB" and "HTTPS" DNS resource record >>> (RR) types to facilitate the lookup of information needed to make >>> connections for origin resources, such as for HTTPS URLs. SVCB >>> records allow an origin to be served from multiple network locations, >>> 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 proposal is inspired by and based on recent DNS >>> usage proposals such as ALTSVC, ANAME, and ESNIKEYS (as well as long >>> standing desires to have SRV or a functional equivalent implemented >>> for HTTP). These proposals each provide an important function but >>> are potentially incompatible with each other, such as when an origin >>> is load-balanced across multiple hosting providers (multi-CDN). >>> Furthermore, these each add potential cases for adding additional >>> record lookups in addition to AAAA/A lookups. This design attempts >>> to provide a unified framework that encompasses the key functionality >>> of these proposals, as well as providing some extensibility for >>> addressing similar future challenges. >>> >>> 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. >>> >>> >>> >>> >>> 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. >>> >>> The IETF Secretariat >>> >>> >> > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Received on Friday, 26 June 2020 08:00:42 UTC