[dtn] Roman Danyliw's No Objection on draft-ietf-dtn-tcpclv4-18: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-dtn-tcpclv4-18: 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:
----------------------------------------------------------------------

Thanks for all of the changes made in response to the LC SECDIR review.  Also,
thank you for the LC SECDIR review, Chris (Wood)!

A reference implementation (as noted in [github-dtn-bpbis-tcpcl]) that includes
a Wireshark dissector is phenomenal (and a bar we should all strive towards
when making a new protocol)

** Section 2.1.  In the definition of the TCPCL Session, “there are two
possible transfer streams; one in each direction, with one stream from each
entity being the outbound stream and the other being the inbound stream.”, what
does this imply about the underlying TCP connections?  It would be worth being
clearer on the relationship between a given stream and the TCP connection.

** Section 3.1. Is the list of provided convergence layer services enumerated
in this section unique to the TCPCL, or would it be expected that all CLs would
implement it?  If the latter, then why isn’t it in the draft-ietf-dtn-bpbis?

** Section 3.2. Per “Each transfer is performed by an sequence of logical
segments of data …”, what is the relationship between a “logical segment” and a
“transfer segment” (defined in Section 2.1)?

** Section 3.3. Figure 4.  What is the state transition from “Established
Session Live” to “Established Session Ending”?  Wouldn’t a session go from live
to idle when the transfer is done (and then session ending)?  Is the Session
live to Session ending perhaps due to an interrupt or termination request while
the transfer is underway?

** Section 4.2.  Given that this new version of the convergence layer is a
“green field” (judging from the list if implementations), why not require TLS
v1.3 as the minimum (rather than TLS v1.2)?

** Section 8.6. (as suggested by Chris in his telechat SECDIR review) This
section isn’t clear on the threat.  It seems to cover material relevant to
validation better aligned with Section 4.4.2.  In particular, the reference to
RFC5280 and reminder to check CRLs would be needed guidance to added to the
Section 4.4.2 paragraph, “Any certificate received during TLS handshake SHALL
be validated up to one or more trusted certificate authority (CA) certificates
…”

** Editorial
Section 2.1. Typo. s/entitys/entities/

Section 2.1. Typo. s/passivley/passively/

Section 2.1. Typo. s/trasnfer/transfer/

Section 2.1. Typo. s/Inititated/Initiated/g

Section 3.1. Typo. s/defintion/definition/

Section 3.1. Typo. s/reciver/receiver/

Section 3.1. Typo. s/transmssion/transmission/

Section 3.2. Typo. s/negligable/negligible/

Section 3.2. Typo. s/by an sequence/by a sequence/

Section 3.3. Typo. s/reeiving/receiving/

Section 3.3. Typo. s/Recevied/Received/

Section 3.4.  Typo. s/polcy/policy/

Section 4.2. Typo. s/contanct/contact/

Section 4.2. Typo. s/behavor/behavior/

Section 4.4.1. Typo. s/assoicated/associated/

Section 4.4.2.  Typo. s/unauthticate/unauthenticated/

Section 4.4.3.  s/Connnection/Connection/

Section 4.6. Typo. s/ mulitplicity/ multiplicity/

Please run a spell-check on the document.  Additional typos were found past
Section 4.6 but were not documented here