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

[Brian Sipos <[e-mail]>]

Erik,
Thank you for the feedback. My comments are inline below with prefix
[BS1].

On Wed, 2020-12-02 at 22:34 -0800, Erik Kline via Datatracker wrote:
> 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&data=04%7C01%7Cbsipos%40rkf-eng.com%7Ca4e2d2be41214ba8ef0a08d897557c38%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637425740708242082%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lnUG8dPA4OP2x6jGMrE8tbW25w756ZAge06q7QHrZJc%3D&reserved=0
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
>  https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dtn-tcpclv4%2F&data=04%7C01%7Cbsipos%40rkf-eng.com%7Ca4e2d2be41214ba8ef0a08d897557c38%7C4ed8b15b911f42bc8524d89148858535%7C1%7C0%7C637425740708242082%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Y%2BvuJGYxkkevXdW9YdewwB23OFu2nUaO52Dc%2BAaAE7Q%3D&reserved=0
> 
> 
> 
> ---------------------------------------------------------------------
> -
> 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)?
> 
[BS1] The intent of the contact header is to provide some backward
compatibility and version negotiation. As Ben also mentioned, because
there is no higher-level protocol negotiation, ALPN would not gain any
benefit to this use by TCPCL.

> [ 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.
> 
[BS1] This negotiation behavior is a carry-over from TCPCLv3 and as you
mentioned can be used by either side to disable keepalive. Technically,
because a receiver doesn't do anything with KEEPALIVE messages, an
entity could still send KEEPALIVE if they absolutely needed to for
local firewall/NAT purposes. The current requirements are about when to
send a KEEPALIVE but don't strictly prohibit sending if not negotiated.
In that situation the idle timeout logic just wouldn't apply, which is
really what the negotiated keepalive interval is for: to know when to
expect to see KEEPALIVE and when to terminate if not seen.

> 
> [[ 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"
> 
[BS1] I'm going to fix these typos.