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
