[DNSOP] John Scudder's No Objection on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-dnsop-dns-tcp-requirements-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the well-written document!

A few comments --

1. I have similar concerns to Ben's regarding the use of BCP as a vehicle to
update the Standards Track documents in question. If I had a better option to
offer at this stage in the document's history, I would, but under the
circumstances I don't. If we had it to do over again, my preference would have
been to progress a small PS to update the Standards Track documents, and a BCP
to provide all the rest of the content. In addition to the points Ben made, my
discomfort also stems from the fact that the advice regarding implementations
has inherently short shelf life (relatively speaking) whereas the updates are
forever (or at least until the updated documents are bis'd).
   I'm not requesting any change with this observation, just putting it out
   there for discussion (without making it a DISCUSS...).

2. In Section 3, another +1 to Ben's comment. In particular the "lastly" part
seemed especially loosy-goosy to me as written, as to what precisely is updated
in RFC 1536. The flow of the prose is nice, but the conclusion is less than
clear. I do think some rewrite of this section would be helpful.

3. Section 6 says applications should perform “full TCP segment reassembly”.
What does that mean? A quick google search doesn’t suggest it’s a well-known
term of art. I'm guessing that what you mean is that the applications should
capture (and log, etc) the bytestream that was segmented and transmitted by TCP?