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

[Alexey Melnikov via Datatracker <[e-mail]>]

Alexey Melnikov 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:
----------------------------------------------------------------------

Thank you for this well written document. It was a pleasure to read!

I agree with Suresh, text about TLS 1.2 compatibility looks dodgy.

I also have some comments I would really like to see replies to:

The document never states byte order for 16/32/64 bit fields. As you are not
using CBOR (or any other format), this can't be presumed to be known.

4.7.  Session Parameter Negotiation

   Enable TLS:  Negotiation of the Enable TLS parameter is performed by
      taking the logical AND of the two contact headers' CAN_TLS flags.
      A local security policy is then applied to determine of the
      negotiated value of Enable TLS is acceptable.  It can be a
      reasonable security policy to both require or disallow the use of
      TLS depending upon the desired network flows.  Because this state
      is negotiated over an unsecured medium, there is a risk of a TLS
      Stripping as described in Section 8.  If the Enable TLS state is
      unacceptable, the node SHALL terminate the session with a reason
      code of "Contact Failure".  Note that this contact failure reason
      is different than a failure of TLS handshake or TLS authentication
      after an agreed-upon and acceptable Enable TLS state.  If the
      negotiated Enable TLS value is true and acceptable then TLS
      negotiation feature (described in Section 4.4) begins immediately
      following the contact header exchange.

While this text is not wrong, I think it is in a wrong section. The rest of
Section 4.7 talks about SESS_INIT message, while the TLS flag was sent in
Contact Header and was already negotiated by this point.

9.1.  Port Number

   Within the port registry of [IANA-PORTS], TCP port number 4556 has
   been previously assigned as the default port for the TCP convergence
   layer in [RFC7242].  This assignment is unchanged by TCPCL version 4,
   but the assignment reference is updated to this specification.  Each
   TCPCL entity identifies its TCPCL protocol version in its initial
   contact (see Section 9.2), so there is no ambiguity about what
   protocol is being used.  The related assignments for UDP and DCCP
   port 4556 (both registered by [RFC7122]) are unchanged.

          +------------------------+----------------------------+
          | Parameter              | Value                      |
          +------------------------+----------------------------+
          | Service Name:          | dtn-bundle                 |
          |                        |                            |
          | Transport Protocol(s): | TCP                        |

Is there another document that will define use over DCCP?

9.6.  XFER_REFUSE Reason Codes
9.7.  SESS_TERM Reason Codes

In both of these sections: I don't think the document say anywhere how
recipients of unrecognized reason codes should handle them. I think the
document should say that they must be treated as "Unknown".