Dear authors, In the revised I-D, please also consider Martin Duke (the transport AD)'s WGLC comments, see the thread at https://mailarchive.ietf.org/arch/msg/dns-privacy/F35q1jpUEPPqaq5gYVM8aYFoQUQ/
Especially around section 10.2 and the demux of DTLS & QUIC if both protocols run on the same port. Martin has suggested some text for this part, let's use it and remove any potential friction in the publication process. Regards -éric On 09/12/2021, 14:40, "Eric Vyncke (evyncke)" <[email protected]> wrote: As usual, when a document is submitted for publication, as the responsible AD, I do my own review of the draft before going to the IETF Last Call. First, thank you Brian for a detailed doc shepherd write-up. Your points about the 'down-ref' are valid and for now I would leave them like they are. Thanks, as well to the WG and the authors Christian, Sara, and Alisson for their work. The document is well written and easy to read: congratulations ! Please find below my review comments: Abstract: should it state where DoQ could be used (i.e., between which DNS functions notably by citing XFR) ? Section 1: s/ this document is intended to specify/ this document specifies/ ? Section 2: please use the real template from BCP14 (section 2 of RFC 8174) Section 5: should there be a sentence "this section is normative" to be consistent with a similar sentence in section 4 ? Section 5.1.2: isn't the 3rd § obvious ? Hence could it be removed ? Unsure whether there is value in the last §, especially as it appears to contradict the previous ones. Section 5.3: should DOQ_REQUEST_CANCELLED also be available when the server wants to close a transaction (e.g., when there are multiple responses/XFR) ? Section 6.3: contains two SHOULD, the general expectation is that the document describes when it is acceptable not to follow the SHOULD. Or perhaps should RECOMMENDED be used ? Section 6.4: same comment as above and also in other places. Section 6.7: should this document formally update RFC 1995, 5936, 7766 ? I think so as it is similar to RFC 9103, which updates those 3 RFCs. Section 7.1: s/ To our knowledge/To the authors' knowledge/ ? Also in " it performs well compared" does it mean "better" or "similar" ? Section 9.3: " due to the prevalence of NAT" is not the only cause as IPv6 nodes often change their IPv6 addresses. Please extend the text here as the DoQ may not have an API to check whether the IPv6 address has changed. Finally, while I am not a native English speaker (but I relied on the Microsoft Word spell-checker on the attached document), I think that there are some nits in the text: - Missing a lot of '-' in some constructions: "general purpose transport", "server initiated transactions", "long term state ", ... - "however" should be followed by a comma - No "n" in "an" in " an unidirectional QUIC stream" - "acknowledgeemnts" - "Provisonal" If the above review points are agreed, then please upload a revised version so that I can continue the publication process. Regards -éric _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
