> On 7 Mar 2022, at 11:10, Lars Eggert via Datatracker <[email protected]> wrote:
>
> Lars Eggert has entered the following ballot position for
> draft-ietf-dprive-dnsoquic-10: Yes
>
> 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-dprive-dnsoquic/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Section 5.5. , paragraph 4, comment:
>> The 0-RTT mechanism SHOULD NOT be used to send DNS requests that are
>> not "replayable" transactions. In this specification, only
>> transactions that have an OPCODE of QUERY or NOTIFY are considered
>> replayable and MAY be sent in 0-RTT data. See Appendix A for a
>> detailed discussion of why NOTIFY is included here.
>
> I think the "SHOULD NOT" should become a "MUST NOT", given that servers don't
> execute it anyway. Also, the "and MAY be sent in 0-RTT data" bit isn't using
> the RFC2119 terms correctly. Suggest to remove it and replace it with "other
> OPCODEs MUST NOT be sent in 0-RTT data".
Hi Lars,
Many thanks for the comment (also made by other reviewers) - both of these
changes are made in the -11 version just published.
And changes below applied too.
Best regards
Sara.
>
> Thanks to Stewart Bryant for their General Area Review Team (Gen-ART) review
> (https://mailarchive.ietf.org/arch/msg/gen-art/knoZG7fEYMwRxN7B5Q5o8YhPcbw).
>
> -------------------------------------------------------------------------------
> All comments below are about very minor potential issues that you may choose
> to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
> will likely be some false positives. There is no need to let me know what you
> did with these suggestions.
>
> Section 1. , paragraph 7, nit:
> - 3. Provide a transport that is not constrained by path MTU
> - ^ ^ - ----- ----
> - limitations on the size of DNS responses it can send.
> - ^ ---
> + 3. Provide a transport that does not impose path MTU
> + ^^^ ^^^
> + limitations on the size of DNS messages it can send.
> + ^ ++
>
> Section 5.3.3. , paragraph 6, nit:
> - expected (e.g. multiple responses to a query for an A record)
> + expected (e.g., multiple responses to a query for an A record)
> + +
>
> Section 5.5. , paragraph 4, nit:
> - Servers MUST NOT execute non replayable transactions received in
> - ^
> + Servers MUST NOT execute non-replayable transactions received in
> + ^
>
> Section 9.5. , paragraph 2, nit:
> - dozen of DNS names. If an application adopts a simple mapping of one
> + dozens of DNS names. If an application adopts a simple mapping of one
> + +
>
> Section 1. , paragraph 16, nit:
>> BE REMOVED BEFORE PUBLICATION)The Github repository for this document is at
>> ^^^^^^
> The official name of this software platform is spelled with a capital "H".
>
> Section 5.2.1. , paragraph 2, nit:
>> : The DoQ implementation encountered an protocol error and is forcibly aborti
>> ^^
> Use "a" instead of "an" if the following word doesn't start with a vowel
> sound,
> e.g. "a sentence", "a university".
>
> Section 5.3. , paragraph 5, nit:
>> rcumstances servers might very well chose to send different error codes. Not
>> ^^^^^
> The modal verb "might" requires the verb's base form.
>
> Section 6.5.1. , paragraph 2, nit:
>> ssion create privacy risks detailed in detailed in Section 9.2 and Section 9
>> ^^^^^^^^^^^^^^^^^^^^^^^
> This phrase is duplicated. You should probably use "detailed in" only once.
>
> Section 6.5.2. , paragraph 5, nit:
>> tickets with a sufficiently long life time (e.g., 6 hours), so that clients
>> ^^^^^^^^^
> This noun is normally spelled as one word.
>
>
>
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
