Dear Peter and Paul, Checking in with you regarding the status of this document. Please let us know whether you approve this document in its current form or further changes are needed.
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-lastdiff.html https://www.rfc-editor.org/authors/rfc9609-lastrfcdiff.html https://www.rfc-editor.org/authors/rfc9609-xmldiff1.html https://www.rfc-editor.org/authors/rfc9609-xmldiff2.html Thank you! RFC Editor/lb > On Dec 5, 2024, at 9:24 AM, Lynne Bartholomew <lbartholo...@amsl.com> wrote: > > Hi, Warren. No worries! We've noted your approval re. this topic on the > AUTH48 status page: > > https://www.rfc-editor.org/auth48/rfc9609 > > Thank you! > > RFC Editor/lb > >> On Dec 5, 2024, at 9:15 AM, Warren Kumari <war...@kumari.net> wrote: >> >> >> >> >> >> On Mon, Dec 02, 2024 at 1:50 PM, Lynne Bartholomew <lbartholo...@amsl.com> >> wrote: >> 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? >> >> >> Sorry, as Paul notes, this is a direct quote, and so the current should >> remain. >> >> W >> >> >> 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
