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

[Brian Sipos <[e-mail]>]

Alexey,
I'm including responses below with prefix "BS: "

On Wed, 2020-02-19 at 07:36 -0800, Alexey Melnikov via Datatracker wrote:
> 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.
> 
BS: As in the earlier reply to Suresh, I am clarifying that the ClientHello
message is the compatibility need and that TLS 1.3 will be the proper baseline
version (which is unchanged in ClientHello from 1.2).

> 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.
> 
BS: You are correct and this is an important overall requirement to be added to
Section 2.

> 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.
> 
BS: This was an error in earlier editing and this block will be moved up to
section "Contact Validation and Negotiation".

> 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?
> 
BS: The DCCP use is loosely defined in RFC 7122 and not being touched by this
change. That is an IRTF assignment.

> 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".
> 
BS: This spec doesn't define any CL- or BP-level logic about how to deal with
most. I did add statements to clarify this and requirements for how a BP agent
should handle undecodable reason codes.