[dtn] Erik Kline's No Objection on draft-ietf-dtn-tcpclv4-23: (with COMMENT)

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

Erik Kline has entered the following ballot position for
draft-ietf-dtn-tcpclv4-23: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


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



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

I'll not disagree with my predecessor, but "[[ discuss ]]" has some random
thoughts that were rattling around in my head.


[[ discuss ]]

[ section 4.* ]

* Instead of upgrading in-session to TLS after CH version and magic field
  verification, Can the TLS session be negotiated first and perhaps quickly
  closed based on some DTN-specific ALPN (perhaps "dtn")?

  Can the use of a DTN-specific ALPN be any help even with in-session TLS
  upgrade (as currently described)?

[ section 4.7 ]

* Selecting the minimum of the two session keepalive parameters, in the case
  where one side uses a value of zero, allows one side to disable all
  keepalives altogether.

  I think this might not be the best negotiated outcome if one node knows that
  it is behind a NAT gateway: that node might need to send session keepalives
  in order to maintain NAT binding state.


[[ nits ]]

[ section 3.4 ]

* "This situation not ideal" -> "This situation is not ideal"

[ section 4.4 ]

* "entity MAY attempt use" -> "entity MAY attempt to use"