On Fri, Sep 10, 2021 at 6:22 PM A. Jean Mahoney <maho...@nostrum.com> wrote:
> Hi Duane, > > On 9/7/21 12:48 PM, Wessels, Duane wrote: > > > > > >> On Sep 3, 2021, at 5:29 PM, Jean Mahoney via Datatracker < > nore...@ietf.org> wrote: > >> > >> Caution: This email originated from outside the organization. Do not > click links or open attachments unless you recognize the sender and know > the content is safe. > >> > >> Reviewer: Jean Mahoney > >> Review result: Ready with Nits > >> > >> Reviewer: Jean Mahoney > >> Review result: Ready with nits > >> > >> A well-written, easy-to-read document. Love Appendix A! > > > > Jean, > > > > Thank you for the review and kind words. > > > >> > >> Question about Appendix A.2 and Updates - Should this document also > update RFC > >> 1536? > >> > >> Current text in A.2: > >> The informational document [RFC1536] states UDP is the "chosen > >> protocol for communication though TCP is used for zone transfers." > >> That statement should now be considered in its historical context and > >> is no longer a proper reflection of modern expectations. > > > > Seems reasonable to consider, assuming a BCP can update an Informational > RFC? > > Any RFC can update any previous RFC? There are some questions about the > use of "Updates" (see draft-kuehlewind-update-tag); different WGs use it > for different things. If you are trying to catch the eye of > implementers, maybe it would help, but perhaps ask your AD. Yup, it should be able to. W > > > > > > > > >> > >> Nits: > >> > >> General - Document status (Informational, Standards Track, etc.) should > be > >> capitalized, and Standards Track is not hyphenated (There's just one > instance > >> of hyphenation). > >> > >> Section 2.4 - 35%of / 35% of > > > > There is an embedded XML comment in the source and apparently it renders > inconsistently. > > I've added more whitespace so it should be fixed regardless. > > > >> > >> Section 3 - transport.[TDNS] / transport [TDNS]. > > > > Fixed. > > > >> > >> Section 5.1 > >> Current: "the steady-state of lost resources as a result is a 'DNS > wedgie'." > >> Perhaps: "the steady state of the resulting lost resources is a 'DNS > >> wedgie'." > > > > Yes, thank you. > > > >> > >> Section 5.2 - Expand the acronym KSK. > > > > Done. > > > > > >> > >> Section 7 - The Acknowledgments section should be located just above the > >> Authors' Addresses section. It looks like the names are supposed to be > in > >> alphabetical order, but they aren't quite. > > > > I moved it to the end of <middle> in the XML source. > > > > > >> > >> Section 9 - fragmenetation / fragmentation > > > > Fixed. > > > > > >> > >> Section 10 - Since DNS over UDP and TCP use / Since DNS over UDP and > TCP uses > > > > Fixed. > > > > > >> > >> Section 11.2 - [ROLL_YOU_ROOT] has a mangled author name and a TBD. > > > > The TBD is fixed. The author names look fine to me, but maybe > "Müller" isn't > > rendering properly for everyone? If thats not it then I'll need you to > be more > > specific. > > The issue is seen in the PDF: Müller > https://tools.ietf.org/pdf/draft-ietf-dnsop-dns-tcp-requirements-12.pdf > > > > > > > > > > > >> > >> Appendix A - The construction "The [RFCNNNN] document..." (in A.3, A.4, > A.5, > >> A.7, and A.13) reads oddly to me. Perhaps "This document [RFCNNNN] ". > > > > Agreed. These have been changed. > > > >> > >> Appendix A.8 - The verb tenses are mixed in this section. > > > > Fixed. > > > > > >> > >> Appendix A.32 - as a a / as a > > > > Fixed. > > > > > >> > >> There are other nits I could pick more easily if this doc was in a > GitHub repo. > >> They can be left to the RPC to clean up. :-) > > > > > > FYI it is in github and I have a pull request for your review at > https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/pull/8 > > I've reviewed the PR. Thanks for making the changes! > > Best regards, > > Jean > > > > > > DW > > > > > > _______________________________________________ > > art mailing list > > a...@ietf.org > > https://www.ietf.org/mailman/listinfo/art > > > -- The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- E. W. Dijkstra
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
