Re: [dtn] I-D Action: draft-ietf-dtn-tcpclv4-09.txt

["R. Atkinson" <[e-mail]>]

My comments below are all non-blocking from a process perspective.

That noted, there do seem to be practical issues that should be 
addressed before this document goes to RFC.  

> On Aug 13, 2018, at 16:36, Joerg Ott <[e-mail]> wrote:
> 
> 1. Section 4.3 seems to suggest on p21 (a node may adapt its operation
>   to an older version of the protocol) the two endpoints might choose
>   using different protocols versions, which is surely problematic.
>   The outcome of this negotiation must be unambiguous.

This seems like a significant interoperability problem that
ought to be resolved prior to publication as an RFC.

> 2. Section 4.4 discusses TLS but this isn't enough.  TLS has lots of
>   parameters, TLS clients may and servers must have certificates.
>   All this interaction needs to be spelled out.  What about the APN
>   to be used for TLS connection setup.  And, of course, we should use
>   TLS 1.3.

Q: Might a compromise be to spell out at least one deployable “profile”
     of TLS for use with this specification, while not precluding folks using
     some other set of TLS parameters if they choose ??

Concur about TLS 1.3.  In fact, I doubt very much the Security Area will
approve any TLS version less than 1.3 — given known/published issues
with previous versions of TLS.

> 4. Section 5.1.1 Keep alive has lost its function.  According to the
>   current text, a keep-alive should be transmitted when the timer
>   expires.  Fine, but this too late because the other entity will
>   time out the connection.  The earlier guidance was that the session
>   timeout occurs if no data was received for _twice_ the keep alive
>   interval.  But this part seems to have gone.  The text would need
>   to be explicit about when to schedule sending keep-alive messages
>   and when to time out.

This sounds like a serious interoperability issue that ought to be resolved
prior to publication.

> 6. Echoing the SESS_TERM message as an ACK is a good idea.  Should
>   we include a nonce here to make sure that an ACK is different from
>   an independently issued SESS_TERM?

I concur that a nonce would be good to add here.

> 7. Session termination in section 6.1 got more complicated.  The text
>   now alllows sending even more segments, whereas the v3 spec
>   essentially said that no data must follow afterwards.  If I receive
>   a SESS_TERM, I should be sure that I can release data processing
>   resources.

This also seems like a problem worth fixing.

> 8. Why not always have the reason code and define one to be unpsecified
>   in SESS_TERM rather than having two-stage processing?

No opinion about the specific issue.  In general, it ought to simplify implementation
and improve interoperability to always have a reason code.  

I would not want to use anything that isn’t specified in an applicable IANA
Registry, but I might specify one in that Registry that means “some other reason”.

Yours,

Ran