Thank you to the authors for having updated the document, and to the chairs for having poked me.
I've requested IETF LC. Thanks everyone. W On Tue, Jul 27, 2021 at 12:34 PM Warren Kumari <[email protected]> wrote: > Dear Authors and WG, > > This document made me grumpy. > > Pointing out nits and similar in documents is one of the few times > that I get to feel superior, and demonstrate my outstanding missing > comma detection abilities... I feel that I've been robbed of this > opportunity in this document -- I only found 4 (four) issues in 57 > pages, for a measly 0.07 errors per page... > > While they are just nits, I'd still appreciate it if the authors could > address them and post a new version -- having the document as clean as > possible before starting IETF LC helps things run smoothly. > > Please SHOUT LOUDLY once you've had a chance to address these (marked > with [O] [P] notation), and I'll kick off LC. > > Thanks, > W > > > > > DNSOP Working Group B. Schwartz > Internet-Draft Google > Intended status: Standards Track M. Bishop > Expires: 18 December 2021 E. Nygren > Akamai Technologies > 16 June 2021 > > > Service binding and parameter specification via the DNS (DNS SVCB and > HTTPS RRs) > draft-ietf-dnsop-svcb-https-06 > > 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. > > 1. Introduction > > The SVCB ("Service Binding") and HTTPS RRs provide clients with > complete instructions for access to a service. This information > enables improved performance and privacy by avoiding transient > connections to a sub-optimal default server, negotiating a preferred > protocol, and providing relevant public keys. > > For example, when clients need to make a connection to fetch > resources associated with an HTTPS URI, they currently resolve only A > and/or AAAA records for the origin hostname. This is adequate for > services that use basic HTTPS (fixed port, no QUIC, no [ECH]). Going > beyond basic HTTPS confers privacy, performance, and operational > advantages, but it requires the client to learn additional > > [O] the client to learn > [P] that the client learn > [R] readability/grammar > > information, and it is highly desirable to minimize the number of > round-trips and lookups required to learn this additional > information. > > [O] and it is highly desirable to minimize the number of > > round-trips and lookups required to learn this additional > information. > [R] Can this sentence be split? The "HTTPS confers ..., but ... and it > is highly desirable..." gets a bit confusing unless you already know > this :-) > > The SVCB and HTTPS RRs also help when the operator of a service > wishes to delegate operational control to one or more other domains, > e.g. delegating the origin "https://example.com"; to a service > operator endpoint at "svc.example.net". While this case can > sometimes be handled by a CNAME, that does not cover all use-cases. > CNAME is also inadequate when the service operator needs to provide a > bound collection of consistent configuration parameters through the > DNS (such as network location, protocol, and keying information). > > This document first describes the SVCB RR as a general-purpose > resource record that can be applied directly and efficiently to a > wide range of services (Section 2). The HTTPS RR is then defined as > a special case of SVCB that improves efficiency and convenience for > use with HTTPS (Section 8) by avoiding the need for an Attrleaf label > [Attrleaf] (Section 8.1). Other protocols with similar needs may > follow the pattern of HTTPS and assign their own SVCB-compatible RR > types. > > All behaviors described as applying to the SVCB RR also apply to the > HTTPS RR unless explicitly stated otherwise. Section 8 describes > additional behaviors specific to the HTTPS RR. Apart from Section 8 > and introductory examples, much of this document refers only to the > SVCB RR, but those references should be taken to apply to SVCB, > HTTPS, and any future SVCB-compatible RR types. > > The SVCB RR has two modes: 1) "AliasMode" simply delegates > operational control for a resource; > > [O] 1) "AliasMode" simply delegates > > operational control for a resource; > > [P] 1) "AliasMode", which simply delegates > > operational control for a resource; > > [R] grammar/clarity. Suggest the same for #2 below. > > 2) "ServiceMode" binds together > configuration information for a service endpoint. ServiceMode > provides additional key=value parameters within each RDATA set. > > 1.1. Goals of the SVCB RR > > The goal of the SVCB RR is to allow clients to resolve a single > additional DNS RR in a way that: > > * Provides alternative endpoints that are authoritative for the > service, along with parameters associated with each of these > endpoints. > > * Does not assume that all alternative endpoints have the same > parameters or capabilities, or are even operated by the same > entity. This is important as DNS does not provide any way to tie > > [O] This is important as DNS > [P] This is important, as DNS > [R] grammar > > together multiple RRs for the same name. For example, if > www.example.com is a CNAME alias that switches between one of > three CDNs or hosting environments, successive queries for that > name may return records that correspond to different environments. > > * Enables CNAME-like functionality at a zone apex (such as > "example.com") for participating protocols, and generally enables > delegation of operational authority for an origin within the DNS > to an alternate name. > > ---- > ... and I found no more errors or even nits below. > > Grump. > W > > > -- > Perhaps they really do strive for incomprehensibility in their specs. > After all, when the liturgy was in Latin, the laity knew their place. > -- Michael Padlipsky > -- The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- E. W. Dijkstra
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
