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