Subject: [DNSOP] Éric Vyncke's No Objection on draft-ietf-dnsop-svcb-https-08: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 02 Mar 2022 04:24:28 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-dnsop-svcb-https-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. Important piece of work as it is
related to some ADD documents as well.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Tim Wicinski for the shepherd's write-up including the
detailed section about the WG consensus even if I regret the absence of
intended status justification.

I hope that this helps to improve the document,

Regards,

-éric

Cosmetic one: I have seen only two "ordinary AAAA/A lookups" and too many "A or
AAAA"... this hurts my IPv6 eyes ;-)

## Section 1
Just a thank you for such a well-written and clear introduction. This comment
also applies to most of the document BTW !

## Section 1.1
"Enable SRV-like benefits (e.g. apex delegation, as mentioned above) for HTTP,
where SRV [SRV] has not been widely adopted", if the "old" SRV has not been
adopted, then what is the probability of having the "new" SVCB adopted ?

Should "HSTS" be expanded at first use ?

## Section 1.2
In "Cooperating DNS recursive resolvers will perform subsequent record
resolution (for SVCB, A, and AAAA records)", is it assumed that only cached
information (A, AAAA) will be used ? Else, it may slow down the resolution of
the SVCB.

In "Additional Section of the response", is it assumed that the response in
this sentence is only a response to a SVCB query ?

## Section 2.2
What is the reason for using uncompressed fully-qualified targetname ? Should
there be some justifications for this absence of compression ?

## Section 2.4.1
Usually when "SHOULD" is used, the specification describes the exception(s).

## Section 2.4.2
Same comment about the use of "SHOULD" (also in many other places)

"In AliasMode, the TargetName will be the name of a domain that resolves to
SVCB, AAAA, and/or A records. ", is it a "will" or a "MUST" ? Should "CNAME"
also be a potential answer (at the expense of another query)?

"this AliasMode record can be replaced by a CNAME" except for apex ...

## Section 2.5.2
Suggest to use a SVCB RR rather than HTTPS to ease the reading of the example.

If compressed DNS name would be allowed (see my comment on sect 2.2) then using
"." would bring nearly no size benefit.

## Section 3

Would a mechanism similar to happy eye ball be used to request SVCB, AAAA, and
A ? It is described later in section 5 but an early hint would not hurt.

"Clients resolve AAAA and/or A records for the selected TargetName, and MAY
choose between them using an approach such as Happy Eyeballs" why not a
"SHOULD" ?

## Section 4.1
"authoritative DNS servers SHOULD return A, AAAA, and SVCB records in the
Additional Section for any TargetNames that are in the zone", shouldn't the
SVCB RRs be in the Answer section? What did I misread ?

## Section 7.2
Strongly suggest not to limit ports to UDP and TCP but either cite UDP and TCP
as examples or include SCTP/DCCP.

## Section 7.4
"For best performance, server operators SHOULD include an "ipv6hint" parameter
whenever they include an "ipv4hint" parameter." There is a bias in the sentence
for "ipv4hint" and it should only applies when both "ipv6hint" and "ipv4hint"
exist.

## Section 11.1
"zone owners SHOULD choose alias target names that indicate the scheme in use",
would a "it is RECOMMENDED" be more applicable and suitable ?