Hi, Warren. Apologies; not sure whether your "This works for me" note refers to the current text or the "Possibly" text. Would you please clarify?
Thank you! RFC Editor/lb > On Nov 25, 2024, at 12:09 PM, Warren Kumari <war...@kumari.net> wrote: > > > > > > On Wed, Nov 20, 2024 at 1:34 PM, Lynne Bartholomew <lbartholo...@amsl.com> > wrote: > Hi, Matt, *Paul, and **Warren. > * Paul, would you please forward your Nov. 18 5:40 PM email to us? We did not > receive it, and we could not find it in the AUTH48 archive > (https://mailarchive.ietf.org/arch/search/?q=9609); we'd like to have a look > at the "To:" and "cc:" lists in your email. > ** Warren, please see our note (just below) re. our question 7), and let us > know if you approve changing "must" to "MUST" and also -- if Paul wants to > keep the update to "SHOULD" -- the update from "should" to "SHOULD". > Paul, we have updated this document per your notes below and added a few > follow-up items. > Re. your reply to our question 7): > =====> Use the capitalized "MUST" from the Introduction section. > (You can now see why prohibiting capitalized text in the abstract is not > always best....) > Because the text in question is a direct quote, we also changed "should" to > "SHOULD". Please let us know any concerns (e.g., maybe you don't want to > indicate quoted text?). For example, if you don't want to change "should" to > "SHOULD", we could do something like the following: > Currently: > Note that [RFC9471] updates [RFC1034] with respect to the use of the TC bit. > It says > | If message size constraints prevent the inclusion of all glue > | records for in-domain name servers over the chosen transport, the > | server MUST set the TC (Truncated) flag to inform the client that > | the response is incomplete and that the client SHOULD use another > | transport to retrieve the full response. > Possibly: > Note that [RFC9471] updates [RFC1034] with respect to the use of the TC bit. > It indicates that if message size constraints prevent the inclusion of all > glue records for in-domain name servers over the chosen transport, the server > MUST set the TC flag to inform the client that the response is incomplete and > that the client should use another transport to retrieve the full response. > > > This works for me… > > Thank you, > W > > > > = = = = = > Re. our question 8) and your reply: > 8) <!-- [rfced] Section 6: We had trouble parsing this sentence. We only see > one scenario, and we could not decipher "comes to a zone" and "but not for > those". Should "to" and "for" be "from"? > Original: > In both of the scenarios above, a validating resolver will be able to detect > the attack if its chain of queries comes to a zone that is signed, but not > for those that are unsigned. --> > =====> You can say "In both of the scenarios listed here" because they are > the two scenarios in the preceding two paragraphs. > Please confirm that the "to" and "for" are OK as is and will be clear to > readers. > = = = = = > Re. your editorial feedback: > In the second sentence of Section 1, you capitalized "They" after the colon, > but that doesn't look right. > We are following the guidance in the 18th edition of the Chicago Manual of > Style, which says (Section 6.67 ("Lowercase or capital letter after a > colon")): > When what follows the colon is not a complete sentence, as in the first > example in 6.65, the first word following the colon is lowercased (unless it > is a proper noun or other term that would normally be capitalized). When, > however, a colon introduces one or more complete sentences, as in the second > and third examples in 6.65, the first word that follows the colon should be > capitalized. This departure from previous editions of this manual—which > recommended capitalization only when a colon introduced more than one > complete sentence—is intended to aid reader comprehension by signaling with a > capital letter that what follows the colon should be read as a complete > sentence. > In Section 3, "DNS cookies" is not a proper noun and the "c" should not be > capitalized (regardless of the mistakes made in RFC 7873). > Reverted. > In Section 3.3, the bulleted list should be reverted to the original text. > The current editorial change does not make it clear that all three conditions > must be met for the attack to be successful. If there is a better way to say > "all three conditions must be met", that's fine, but the edit makes it look > like any of the three can be met for the attack to be successful. > Reverted. > In Section 4.2, please do not spell out "(Truncated)". RFC 1035 was not well > edited, and this is not an actual abbreviation. I note that you (correctly) > did not spell out "NS" at the beginning of Section 3. > Reverted. > = = = = = > The latest files are posted here. Please refresh your browser: > https://www.rfc-editor.org/authors/rfc9609.txt > https://www.rfc-editor.org/authors/rfc9609.pdf > https://www.rfc-editor.org/authors/rfc9609.html > https://www.rfc-editor.org/authors/rfc9609.xml > https://www.rfc-editor.org/authors/rfc9609-diff.html > https://www.rfc-editor.org/authors/rfc9609-rfcdiff.html > https://www.rfc-editor.org/authors/rfc9609-auth48diff.html > https://www.rfc-editor.org/authors/rfc9609-xmldiff1.html > https://www.rfc-editor.org/authors/rfc9609-xmldiff2.html > Matt, we have noted your approval on the AUTH48 status page: > https://www.rfc-editor.org/auth48/rfc9609 > Thank you! > RFC Editor/lb > On Nov 19, 2024, at 7:56 AM, Matt Larson <matt.lar...@icann.org> wrote: > Dear RFC Editor, > As a co-author, I’m signing off on this document. I agree with all of Paul’s > comments and changes. It is ready for publication from my perspective. > Thanks, > Matt > On Nov 18, 2024, at 5:40 PM, Paul Hoffman <paul.hoff...@icann.org> wrote: > Thank you for your review of RFC-to-be 9609. I'm sending this as one of the > three authors. > In-line questions: > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in the > title) for use on <https://www.rfc-editor.org/search>. --> > =====> "DNS caching", "root zone" > 2) <!-- [rfced] Please note that because this document is obsoleting RFC > 8109, it will replace RFC 8109 as BCP 209. Please let us know any concerns. > --> > =====> No concerns. > 3) <!-- [rfced] Abstract: As Abstracts should be self-contained per Section > 4.3 of RFC 7322 (https://www.rfc-editor.org/info/rfc7322) and not contain > internal citations, we moved this sentence to the end of the Introduction > section. Please let us know any objections. > Original: > See Appendix A > for the list of changes from RFC 8109. > ... > This document only deals with recursive name servers (recursive resolvers, > resolvers) for the IN class. > Currently: > ... > This document only deals with recursive name servers (recursive resolvers, > resolvers) for the IN class. > See Appendix A for the list of changes from [RFC8109]. --> > =====> This change is fine. > 4) <!-- [rfced] Section 1: Does '(recursive resolvers, resolvers)' mean > '(referred to in this document as "recursive resolvers" or simply > "resolvers")' or something else? Please let us know how/if this text should > be clarified. > Original: > This document only deals with recursive name servers (recursive resolvers, > resolvers) for the IN class. --> > =====> It means what you guessed. The wording could be changed to > ...with recursive name servers (also called "recursive resolvers" and just > "resolvers") for the IN class. > 5) <!-- [rfced] Section 3: We see that "EDNS(0) [RFC6891]" in RFC 8109 was > changed to "EDNS0 [RFC6891]" in this document. We also see that RFC 6891 uses > "EDNS(0)", except for "DNS EDNS0 Options registry" in its Section 9. Will the > reason for this change be clear to readers? > Original: > The recursive resolver SHOULD use EDNS0 [RFC6891] for priming queries and > SHOULD announce and handle a reassembly size of at least 1024 octets > [RFC3226]. --> > =====> Yes, "EDNS0" is used in some documents after RFC 6891. RFC 6891 chose > to use an obscure nomenclature. > 6) <!-- [rfced] Section 3.2: We could not tell which method is "the random > method listed above". Will this text be clear to readers? > Original: > However, > the random method listed above SHOULD be used for priming. --> > =====> Good catch. You can remove "listed above" because it is in the same > section. > 7) <!-- [rfced] Section 4.2: Regarding this text: > Original: > Note that [RFC9471] updates [RFC1035] with respect to the use of the TC bit. > It says "If message size constraints prevent the inclusion of all glue > records for in-domain name servers, the server must set the TC (Truncated) > flag to inform the client that the response is incomplete and that the client > should use another transport to retrieve the full response." > We found "[RFC9471] updates [RFC1035]" confusing, because RFC 9471 is listed > as updating RFC 1034 only. Should different wording be used in place of > "updates", to avoid confusion? For example, would > "[RFC9471] could be said to update [RFC1035]" be appropriate? > =====> It should have instead said > Note that [RFC9471] updates [RFC1034]... > Also, when verifying this quoted text from RFC 9471, we found that two very > similar variations of this text appear in RFC 9471: one in its Abstract and > one in its Introduction section. > Which text is preferred for this document - the text from RFC 9471's Abstract > or its Introduction section? In other words, are > "over the chosen transport", "MUST" vs. "must", and "SHOULD" vs. > "should" of any significance here? If yes, please let us know whether this > citation and text should point to the Abstract of RFC 9471 or its > Introduction section; we suggest specifying where the quoted text comes from. > RFC 9471's Abstract: > If > message size constraints prevent the inclusion of all glue records for > in-domain name servers, the server must set the TC (Truncated) flag to inform > the client that the response is incomplete and that the client should use > another transport to retrieve the full response. > RFC 9471's Introduction section: > If message size constraints prevent > the inclusion of all glue records for in-domain name servers over the chosen > transport, the server MUST set the TC (Truncated) flag to inform the client > that the response is incomplete and that the client SHOULD use another > transport to retrieve the full response. --> > =====> Use the capitalized "MUST" from the Introduction section. > (You can now see why prohibiting capitalized text in the abstract is not > always best....) > 8) <!-- [rfced] Section 6: We had trouble parsing this sentence. We only see > one scenario, and we could not decipher "comes to a zone" and "but not for > those". Should "to" and "for" be "from"? > Original: > In both of the scenarios above, a validating resolver will be able to detect > the attack if its chain of queries comes to a zone that is signed, but not > for those that are unsigned. --> > =====> You can say "In both of the scenarios listed here" because they are > the two scenarios in the preceding two paragraphs. > 9) <!-- [rfced] Please review the "Inclusive Language" portion of the online > Style Guide at > <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. --> > =====> Nothing to change here. > Editorial: > In the second sentence of Section 1, you capitalized "They" after the colon, > but that doesn't look right. > In Section 3, "DNS cookies" is not a proper noun and the "c" should not be > capitalized (regardless of the mistakes made in RFC 7873). > In Section 3.3, the bulleted list should be reverted to the original text. > The current editorial change does not make it clear that all three conditions > must be met for the attack to be successful. If there is a better way to say > "all three conditions must be met", that's fine, but the edit makes it look > like any of the three can be met for the attack to be successful. > In Section 4.2, please do not spell out "(Truncated)". RFC 1035 was not well > edited, and this is not an actual abbreviation. I note that you (correctly) > did not spell out "NS" at the beginning of Section 3. > Again, thanks for your review! > --Paul Hoffman -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
