On Fri, Sep 10, 2021 at 6:22 PM A. Jean Mahoney <mahoney@xxxxxxxxxxx> 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 <noreply@xxxxxxxx> 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
> art@xxxxxxxx
> 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
complexities of his own making.
-- E. W. Dijkstra
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
