Subject: [art] Artart last call review of draft-ietf-dnsop-dns-tcp-requirements-12

From: Jean Mahoney via Datatracker <[email-masked]>
Date: Fri, 03 Sep 2021 17:29:17 -0700

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!

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.

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

Section 3 - transport.[TDNS] / transport [TDNS].

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'."

Section 5.2 - Expand the acronym KSK.

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.

Section 9 - fragmenetation / fragmentation

Section 10 -  Since DNS over UDP and TCP use  / Since DNS over UDP and TCP uses

Section 11.2 - [ROLL_YOU_ROOT] has a mangled author name and a TBD.

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] ".

Appendix A.8 - The verb tenses are mixed in this section.

Appendix A.32 - as a a / as a

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. :-)

Thanks!
Jean

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 7 Sep 2021 17:48:03 +0000

> On Sep 3, 2021, at 5:29 PM, Jean Mahoney via Datatracker <[email-masked]> 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

Jean,

Thank you for the review and kind words.

>   is no longer a proper reflection of modern expectations.

Seems reasonable to consider, assuming a BCP can update an Informational RFC?

> 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.

>   Perhaps: "the steady state of the resulting lost resources is a 'DNS

Yes, thank you.

> Section 5.2 - Expand the acronym KSK.

Done.

> 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&uuml;ller" isn't
rendering properly for everyone?  If thats not it then I'll need you to be more
specific.

> 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.

> 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

DW

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Fri, 10 Sep 2021 17:21:42 -0500

Hi Duane,

> 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.

> rendering properly for everyone?  If thats not it then I'll need you to be more

The issue is seen in the PDF: MÃ¼ller
https://tools.ietf.org/pdf/draft-ietf-dnsop-dns-tcp-requirements-12.pdf

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art
>

---

From: Warren Kumari <[email-masked]>
Date: Fri, 10 Sep 2021 19:19:21 -0400

On Fri, Sep 10, 2021 at 6:22 PM A. Jean Mahoney <[email-masked]> 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

Yup, it should be able to.
W

> > 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
>

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Bob Hinden <[email-masked]>
Date: Sat, 11 Sep 2021 09:03:48 -0700

Hi Warren,

> On Sep 10, 2021, at 4:19 PM, Warren Kumari <[email-masked]> wrote:
> 

Are you sure?

For example, can an “Experimental" RFC update an RFC at “Standard”?    Can an RFC from one Stream update an RFC in another Stream?   Lots of other cases come to mind.

This seems a lot more subtle than any RFC can update any other RFC.

Bob

---

From: tom petch <[email-masked]>
Date: Mon, 13 Sep 2021 09:23:28 +0000

From: art <[email-masked]> on behalf of Bob Hinden <[email-masked]>
Sent: 11 September 2021 17:03

Hi Warren,

Are you sure?

<tp>

I agree.  A case in point is RFC8966 which deprecates TLS1.0 and TLS1.1 and updates rather a lot of RFC in doing so.  Some of these are ISE and the permission of the ISE Editor was sought, and obtained, before going ahead so I do not think that any I-D from one stream can update any I-D from another.

Tom Petch

Bob

---

From: Warren Kumari <[email-masked]>
Date: Mon, 13 Sep 2021 21:24:37 -0400

On Mon, Sep 13, 2021 at 5:23 AM tom petch <[email-masked]> wrote:

> For example, can an “Experimental" RFC update an RFC at “Standard”?    Can
> an RFC from one Stream update an RFC in another Stream?   Lots of other
> cases come to mind.
>
> I agree.  A case in point is RFC8966 which deprecates TLS1.0 and TLS1.1
> and updates rather a lot of RFC in doing so.  Some of these are ISE and the
> permission of the ISE Editor was sought, and obtained, before going ahead
> so I do not think that any I-D from one stream can update any I-D from
> another.
>
> Tom Petch
>
> Bob
>
>
It seems that some set of lists got dropped from some set of replies.

As Robert Sparks helpfully pointed out on last-call list, I was only
talking about this "particular potential BCP updating a particular
Informational RFC both in the IETF stream.".
Mirja, Suresh, and others have tried addressing what exactly Updates
actually means (e.g
https://datatracker.ietf.org/doc/draft-kuehlewind-update-tag/ ), and the
answer is currently still murky and unclear.

I can, however, confidently say that this particular potential BCP can very
probably update this particular Informational RFC. Probably.... It somewhat
depends on how much other ADs think that it is useful that readers of
RFC1536 know about this other document. The text in RFC1536 isn't
incredibly specific, and different people have different interpretations on
"Updates:" -- I personally fall on the side of "Updates/Updates by..." is
close to "other related important documents that you should really read to
avoid foot canons". Other people feel that Updates is more "Replace text A
with text B" or "Skip step 23 if bit 1 is set".

One of the best things about the IETF is that we prefer pragmatism and
Spencer's "Do the Right Thing" creed over strict rules,regulations and
policy.
One of the worst things about the IETF is that we prefer pragmatism and
Spencer's "Do the Right Thing" creed over strict rules,regulations and
policy.

W

---

From: John Kristoff <[email-masked]>
Date: Fri, 17 Sep 2021 14:47:47 -0500

On Mon, 13 Sep 2021 21:24:37 -0400

> Informational RFC both in the IETF stream.".

Hi Warren et al.,

I have this in the appendix:

The "historical context" notion is my interpretation of how to handle
that early document's statement.  Is this reasonable?  Should I change
this?

John

---

From: Warren Kumari <[email-masked]>
Date: Fri, 17 Sep 2021 16:00:08 -0400

> that early document's statement.  Is this reasonable?  Should I change
Nah, I think that that is perfectly reasonable.

W