Reviewer: Matt Brown Review result: Ready with Issues 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
