The IESG has received a request from the Domain Name System Operations WG (dnsop) to consider the following document: - 'Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)' <draft-ietf-dnsop-svcb-https-12.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2023-04-03. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Your attention please... This is a second IETF LC for this document - it was originally approved on 2022-05-25 and sent to the RFC Editor. However, it had a reference to a reference to a document (ECH in the TLS WG) which will still be many months in the making -- and other documents are now waiting on this document. As the ECH reference was for an "optional feature", after discussions with the authors, WG, chairs, chairs of TLS, authors of ECH, authors of the other documents, IESG, etc we asked the RFC Editor to return the document. It has now had the ECH feature removed, and has had another WGLC, and this is the IETF LC on the removal of the text. It probably didn't need all of this process stuff, but I figured it is better to have transparency (and, yes, this is being coordinated with the documents that rely on this doc!) Please see the shepherd's writeup if this is confusing... Diff from the previously approved version: https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-svcb-https-11&url2=draft-ietf-dnsop-svcb-https-12&difftype=--html We now return you to your regularly scheduled LC text... 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 HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as 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 use with HTTP [HTTP]. 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). The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
