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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
