Lars Eggert IESG ballot comments
huitema opened this issue · comments
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".
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:
-
- Provide a transport that is not constrained by path MTU
-
^ ^ - ----- ---- -
limitations on the size of DNS responses it can send. -
^ ---
-
- 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.