Re: [DNSOP] AD Review of: draft-ietf-dnsop-svcb-https

[Warren Kumari <[e-mail]>]

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 <[e-mail]> 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