Last Call Review of draft-ietf-dnsop-svcb-https-12
review-ietf-dnsop-svcb-https-12-dnsdir-lc-brown-2023-04-02-00

I have been selected as the DNS Directorate reviewer for this draft. The DNS
Directorate seeks to review all DNS or DNS-related drafts as they pass through
IETF last call and IESG review, and sometimes on special request. The purpose
of the review is to provide assistance to the ADs. For more information about
the DNS Directorate, please see https://wiki.ietf.org/en/group/dnsdir

As this is the second LC for this draft and it has already been subject to
significant discussion and review I am not rendering any review opinion on the
merits and drawbacks of the proposed RR types themselves, but am solely
focusing on the clarity of the draft and its interaction with the wider DNS
ecosystem.

On that basis, I believe this draft is ready with issues as described below:

**Issue: DNS terminology misuse**

S1.3 states “Additional DNS terminology intends to be consistent with
[DNSTerm]”. No previous definitions for “origin” or “delegation” are provided
before this statement (RFC6454 is referenced in the definition of “service”,
but not as a specific definition for “origin”).

Both “origin” and “delegation” are then used in the draft in a manner
inconsistent with their definition in [DNSTerm]. The third bullet of section
1.1 provides a clear example of the terminology confusion of both terms in a
single sentence - the usage of “origin” in this bullet point is invalid
regardless of whether “web origin” or “dns origin” is intended, and there is
definitely no “delegation” or zone cut being created by the SVCB RR at either
the apex or any other domain name.

***Origin***

Despite the S1.3 definition above, for the majority of the draft, origin
appears to be used in reference to the Web Origin concept requiring the reader
to resolve the conflict of whether the [DNSTerm] meaning (as required by
section 1.3) or the RFC6454 meaning (as almost all contextual clues suggest) is
intended.

This would be most obviously remedied by having section 1.3 explicitly state
that “origin” in the document refers to the RFC6454 concept, not the DNS
concept, and/or explicitly specifying “web origin” throughout the document
rather than “origin” for maximum clarity.

***Delegation***

The functionality of an AliasMode SVCB RR is described as enabling “delegation”
(which requires NS records and a zone cut per [DNSTerm]) while in reality the
proposed functionality is that of a CNAME, not a delegation.

The problematic usage is primarily found in Section 1 and adoption of the
“aliasing” and "separation of concerns" terminology that is more prevalent in
the description of AliasMode’s behaviour in section 2 throughout section 1 to
completely eliminate any mention of "delegation" would resolve the issue.

The following feedback is at the “Nit” level, rather than being an “Issue”:

**Nit: Client behaviour terminology inconsistency and implementation
assumptions**

In section 3 describing client behaviour there is a wide range of terminology
used to describe endpoints - “priority-ordered endpoints” (first sentence),
“alternative endpoints” (step 4), “known endpoints” (step 5), “priority list”
(para 6) and “resolved list” (para 7).

In addition to adding confusion (e.g. is there intended to be a difference
between alternative and known endpoints at step 4 and 5 or is this the same
list by 2 different names?) , the description of “appending” a default record
to the “priority list” (without a specified priority) when a AliasMode record
has been encountered described in para 5, assumes behaviour (sorting of
returned RRs) that has not been specified or described in the “SVCB resolution”
steps above (which deal only with a set of "alternative endpoints") - and
indeed is not specified until the following paragraph.

Clarity of the intended behaviour in this section would be improved by:
1) Using a single name to refer to the list of endpoints throughout the section
(or if multiple lists are intended, clarifying that) 2) Either
  A) Requiring clients to sort the list as an explicit step of the “SVCB
  resolution” procedure, after which the "append" instruction (without explicit
  priority) from para 5 makes sense, OR B) Modifying para 5 to specify an
  explicit priority that the default endpoint must  be added to the (at this
  point unordered) endpoint list with, so the ordering behavior described in
  para 6 has all the information required to function.

Being explicit about when and how the priority ordering must happen at this
step would also allow clarity to be improved in this section by explicitly
showing how and where in this resolution process the additional requirements
from section 2.4.1 (random shuffling) and section 5.1 (ignoring priority to
re-use an existing connection that is consistent with the SVCB response) are
expected to be implemented by clients.

**Nit: Other vague and general statements **

The draft contains a number of vague statements that add confusion rather than
clarity for the reader:

S 2.4.2 para 5 - “...this AliasMode record can be replaced by a CNAME at the
same owner name, which would likely improve performance.”

I’m unclear on the CNAME performance benefit here, and I expect other readers
may be too - is it just in the case of non-conforming recursive resolvers which
will perform additional processing for CNAME, but not SVCB, and therefore SVCB
will require an extra lookup over CNAME? Or is there some more subtle
interaction or downside to using AliasMode that I (and maybe other readers) am
missing here?

If you’re going to state a (potential) performance improvement, you should
explain why or how that performance improvement can be gained, so implementers
can make an informed decision as to whether AliasMode or CNAME best fits their
deployment.

More broadly, a sentence hinting that a new feature being introduced by the
draft should sometimes, maybe be avoided because it will hinder performance, in
the middle of a section focused on the technical definition of the feature
feels discordant and out of place. Either this section should more fully
explain the benefits/trade-offs of AliasMode and when to use it vs CNAME as
part of the formal definition, or if this is purely an
implementation/performance focused note, then it would be more suitably located
at section 10.2 rather than in the middle of this section where it distracts
from the key information of how AliasMode behaviours.

S 6 - “Standards authors should consider carefully …”

No advice is provided to future standards authors on what aspects of the
decision they should carefully consider - e.g. are there DNS operation related
factors that should be taken into consideration when deciding whether to use
SVCB or a new SVCB-compatible RR-type, or are the careful considerations purely
based on application/protocol needs such as the wildcard/CNAME issues that
motivated the HTTPS RR type?

Is there a preferred or safe default option for a protocol standard author?
Should they prefer to add a new RR type over using SVCB, or SVCB with
additional SvcParamKeys?

While impossible to predict all of the future considerations that will be
required, the draft should at least provide some guidance on the known
pros/cons of each path.

S 8 - “ If the SVCB RRSet contains no compatible RRs, the client will generally
act as if the RRSet is empty.”

In what situations and conditions will the client behave outside the
“generally” expected behaviour here? As a zone/server operator, how am I
expected to interpret and respond to this statement?

Rather than the vague “generally” currently used here, it would be preferable
for this paragraph to refer back to the clearly specified client behaviour
specified in section 3 instead of leaving the reader with questions about what
“generally” covers or does not.  Or if this is referring to something other
than the section 3 specified behaviour, those additional edge-cases must be
specified.

**Nit: Other terminology issues**

S8 - “compatible” confusion

The intermixing of the definition of the mandatory key, and the “compatible”
concept in S 8 adds unnecessary difficulty for the reader having to switch
between two concepts throughout the section - consider breaking section 8 into
two sub parts, 8.1 - defining the mandatory key and its semantics, 8.2 -
defining the “compatible” concept, with a clear bullet point list of criteria
as per the section 6 example of how SVCB-compatible is defined.

The importance of clarity for the definition of “compatible” is heightened
given the draft defines multiple types of compatibility, one of which is
defined by a specific term (SVCB-comaptible) and the other of which simply uses
the unqualified english word itself. There is a risk (albeit low given
surrounding context in most cases) that a reader may conflate the unqualified
“compatible” term defined here, as also encompassing the SVCB-compatible
concept from section 6.

This risk could be avoided by defining the S8 compatibility concept with its
own specific term as well so that the level of specificity between the two
concepts of compatibility in the draft is equal.

S10.2 - “nonconforming”

This should likely be hyphenated: “non-conforming” to match with equivalent
usage in section 5.