On 2026/07/21 00:08, [email protected] wrote:
Ray,
While reviewing this document during Final Review, please resolve (as
necessary) the following questions, which are also in the source file.
1) <!-- [rfced] May we adjust the text below as follows for readability (and to
make the sentence/verb more active)?
Original:
In [RFC9619], RFC1035 is updated to only permit a single question in a
QUERY (OpCode=0) request.
Perhaps:
[RFC9619] updates RFC 1035 [STD13] to only permit a single question in a
QUERY (OpCode=0) request.
-->
Yes, that's fine.
I note that in para. 1 of the intro the [STD13] refererence label has
become separated from the word DNS:
"A commonly requested DNS feature [STD13] is "
This looks odd to me, but if that's the preferred style...
2) <!-- [rfced] Please review Figures 1 and 2 in the text and compare with the
same figures in HTML and PDF. Are the plus signs intended as markers? They do
not appear in the HTML or PDF files. Please let us know if this is as expected or
if an update is needed.
-->
In the ASCII art they just denote the 16 separate bits of the two octets
in each row. I don't think it matters that they're omitted from the
non-ASCII document versions.
3) <!-- [rfced] What is the subject of the sentence below? Is it correct that this is
the continued definition of "OPTION-DATA", so the text should be indented?
Original:
A list of 2-octet values in network order (MSB first) each specifying
a DNS RRTYPE that must be for a data RRTYPE as described in
Section 3.1 of [RFC6895].
-->
Hmm, that's slightly tricky.
It *is* the definition of the option data, but the intent was that
Figure 1 and accompanying text replicate the ยง6.1.2 generic EDNS0 option
format spec from RFC 6891, and that Figure 2 and following text is then
the specific definition of the option data for this RFC.
As such, it isn't strictly a continuation of the three item list from
the preceding paragraph. Perhaps just add this to the start of the
paragraph?
OLD:
A list of 2-octet values in network order ...
NEW:
The OPTION-DATA is a list of 2-octet values in network order ...
4) <!-- [rfced] For readability, we have added additional punctuation to the
text
below (and have made the one sentence into two separate sentences). Please
review.
Original:
This might happen, for example, if the primary query resulted in a NOERROR
response but a QTx query resulted in a SERVFAIL, or if the primary response
has AA=0 but a QTx response has AA=1, such as might happen if the NS and DS
records were both requested at the parent side of a zone cut.
Current:
This might happen, for example, if the primary query resulted in a NOERROR
response, but a QTx query resulted in a SERVFAIL. This could also happen
if the primary response has AA=0, but a QTx response has AA=1, which might
happen if the NS and DS records were both requested at the parent side of a
zone cut.
-->
That's fine.
On a related note, I see that every instance of e.g. and i.e. is now
followed with a comma. This is contrary to my British English writing
style.
5) <!-- [rfced] Please review the following questions regarding the terminology
and abbreviations used in this document:
a) We note different capitalization of the terms below. Please review and let
us know how to update each item for consistency:
Question section vs. question section
Answer section vs. answer section
MQTYPE-Query vs. MQType-Query
Question section, Answer section, MQTYPE-Query
b) FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
most significant bit (MSB)
Internet Systems Consortium (ISC)
-->
That's fine.
6) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
I can't see anything that requires any changes.
thanks!
Ray
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
