[tcpm] Erik Kline's Yes on draft-ietf-tcpm-rfc793bis-25: (with COMMENT)

[Erik Kline via Datatracker <[e-mail]>]

Erik Kline has entered the following ballot position for
draft-ietf-tcpm-rfc793bis-25: Yes

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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/



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

[ general ]

* Thanks for all this.

* I had several questions around "security/compartment" test, but
  Appendix A.1 was very helpful.

* I debated whether or not the source routing stuff (3.9.2.1) should rise
  to the level of a DISCUSS or not.  Please let me know what you think.

[S2, nit]

* "including examples of A, B, C" -> "A, B, and C", perhaps

[S3.1, nit]

* Urgent Pointer, "is only be interpreted"

  -> "is only to be interpreted"
  -> "is only interpreted"

  or something

[S3.3.2, nit]

* "These transitions are not not explicitly shown" -> double (k)not?

[S3.4, nit]

* "on an incoming segments" -> "on an incoming segment", perhaps

[S3.5, question]

* Is there an example of what possible use a RST w/ data could serve?

  I didn't see anything in S3.10.7(.*) that indicated the data in a segment
  with the RST flag set could get processed (I may have missed it).

[S3.7.1, comment]

* In networks where NAT64 is employed, the default MSS assumed by a sender
  will differ from the default assumed by a receiver, since the address
  families sent and received will be different.

  This may bolster the case for MAY-3 being a SHOULD (or even a MUST ;-) but,
  more to the point, may be a caveat to note w.r.t. SHLD-5.

  Alas, I could find no discussion of MSS option handling in RFC 6146,
  so I wonder if that's something that we missed...

[S3.9.1, nit]

* "use the same local address is used that was used" ->
  "use the same local address that was used", perhaps

[S3.9.2.1]

* I feel like there should be some additional caveat about security
  implications of support for source routing.  RFC 6274, for example, says
  packets with LSRR (6274s3.13.2.3) and SSRR (6274s3.13.2.4) options should
  be dropped, citing various security concerns.

  I'm not sure there needs to be a lot of text; perhaps just an observation
  that some end systems may not support the source route semantics described
  here for security (or policy) reasons?

[S3.9.2.2]

* I feel like ICMPv6 DestUnreach 2 and 4 should be treated as hard errors,
  but haven't found any explicit documentation yet.  Was the intention here
  to imply that ICMP DU 2-4 includes both ICMPv4 and v6, or just ICMPv4?
  If the latter, should we make a statement about ICMPv6?

  <aside>
  My expectation doesn't exactly line up with Linux's icmpv6_err_convert()
  behavior, it seems.
  </aside>

  I'm fine with the text as is -- given that the TCP/IPv6 Internet generally
  functions just fine today :-) -- just curious for the sake of clarification.

[S3.10.{1,2}, nit]

* These sections introduce "foreign socket" whereas I believe all other
  mentions are "remote socket" (and, indeed, the error strings also say
  "remote socket").

  Maybe s/foreign/remote/g ?