(1) RFC is Standards Track, and this is the correct RFC type.
(2)
Technical Summary:
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.
Working Group Summary:
Working group consensus was strong, though it was rough in spots. During WGLC,
discussions came up about the syntax of the records. The issues raised about
the syntax was discussed in depth, and the issues raised were very much the
rare exception rather than the rule.
Syntax Discussion:
https://mailarchive.ietf.org/arch/msg/dnsop/fePoVb6vhryjzaMFSx_lzUcqLPk/
WGLC thread:
https://mailarchive.ietf.org/arch/msg/dnsop/SXnlsE1B8gmlDjn4HtOo1lwtqAI/
This document carried on to the RFC Editor's quere where it was sitting for a
long time waiting for the completion of draft-ietf-tls-esni. This turned out
to be taking much longer than had been expected, and this document was holding
up other documents in other working groups, so after some discussion, the
document was brought back from the RFC Editor's queue to the working group, the
authors removed the sections referncing the ECH options to place in a new
document, and republished. Their changes are here:
https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-svcb-https-11&url2=draft-ietf-dnsop-svcb-https-12&difftype=--html
Also, the Area Director's discussion of this process
https://mailarchive.ietf.org/arch/msg/dnsop/5aiWtJbmAoqj7-5oD03Rgw1PEoo/
Document Quality:
While these are updates to existing standards, there is an implementation
section where several versions of open source software has implemented this.
Document Shepherd: Tim Wicinski
Responsible Area Director: Warren Kumari
(3) The Document Shepherd did a detailed review of the document for content as
well as simple editorial checks (pelling/grammar). The shepherd feels the
document is ready for publication.
(4) The Document Shepherd has no concerns on the depth or breadth of the
reviews.
(5) There is no need for broader review.
(6) There are no concerns from the document shepherd.
(7) No IPR disclosures
(8) There is no IPR
(9) The WG Consensus on this document is strong.
(10) There has been no appeals.
(11)
== Outdated reference: draft-ietf-httpbis-semantics has been published as
RFC 9110
-- Possible downref: Normative reference to a draft: ref. 'HTTP'
** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110)
** Downref: Normative reference to an Informational RFC: RFC 7871
== Outdated reference: draft-ietf-quic-http has been published as RFC 9114
(12) No formal review needed
(13) All references have been identified as normative or informative.
(14) All normative references are in a clear state
(15) There is one downward normative reference to RFC 7871, which has one
existing downward reference.
(16) This RFC will not change any existing RFCs.
(17) The document shepherd confirmed the consistency and references of the IANA
Considerations section are accurate.
(18) The new IANA Registry "Service Binding (SVCB) Parameter Registry" is
created as a First Come First Serve, and does not require any Expert Reviews.
(19) N/A
(20) No Yang Necessary
