Subject: [MMUSIC] Review of draft-ietf-mmusic-udptl-dtls-02

From: Oscar Ohlsson <[email-masked]>
Date: Wed, 18 Dec 2013 13:46:19 +0000

I have reviewed draft-ietf-mmusic-udptl-dtls-02, and overall the document looks good. A couple of comments and suggestions are included below.

Regards,

Oscar

--------------------------------------------------------------------------------

Abstract

- To introduce the reader to the topic, maybe you should mention already in the abstract that UDTPL is used for T38 fax transmission.

Section 1

- Remove the topmost row "Protocol" in Table 1 and Table 2 or somehow indicate that is a header.

- Not sure "DTLS association" is the correct term. I've seen other documents using the term "DTLS connection" instead, for example RFC 5238, Section 3.4:

       DTLS uses the concepts of sessions and connections.  A DTLS

       connection is used by upper-layer endpoints to exchange data over a

       transport protocol.  DTLS sessions contain cached state information

       that is used to reduce the number of roundtrips and computation

       required to create multiple DTLS connections between the same

       endpoints.

  If you decide to change it, then make sure to change all occurences in the document.

Section 3.1

- To me "DTLS over UDP" sounds better than "DTLS over the UDP"

- The third bullet "If the endpoint supports ..." implies that a fingerprint has to be included also in the case when the endpoint certificate is not self signed, which is unnecessary. Is this what you intended?

Section 4.3

- Regarding the sentence:

    The duration of maintaining the previous set of keys after the finish of the DTLS

    handshake is out of scope for this document.

   Instead of leaving the timer out of scope you do could do the same way as in RFC 5764, Section 5.2 and use the UDP maximum segment lifetime (MSL).

Appendix A

- The title should be changed from "Example" to "Examples"

Appendix A.1

- I don't see why you think it's important to add SIP Identity (RFC4474) to the example. In my opinion it just makes the example longer and does not have much to with the main content of the document. I would suggest to remove it and instead add a sentence saying that it is possible to combine the message flow in the example with SIP Identity. Also I think it is questionable how much security SIP Identity provides when it is only used in one of the directions.

If you remove SIP Identity from the example, then also make sure to change the reference to the example in Section 5.

Appendix A.2

- The STUN connectivity check described in Section 4.2.2 is missing from the message flow in Figure 1. The same is true for Figure 6 in A.3.

- The description of the individual message is incomplete ("Message (1):").

- Change "indicates" to "contains" in the sentence "The SDP fingerprint attribute in the SDP offer indicates". The same sentence occurs in three more places in the appendix.

- In the description of message 4, remove "the" in the sentence  "...from the Alice's certificate... "

Appendix A.3

- Add "the" in front of "DTLS association" in the sentence:

    In this example flow, Alice acts as the passive endpoint of DTLS

    association and Bob acts as the active endpoint of DTLS association.

- Add "the" in front of "SDP offer and "is" before "shown" in the sentence:

     SDP offer included in the SIP re-INVITE request shown in Figure 7.

--------------------------------------------------------------------------------

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Dec 2013 07:59:11 +0000

Hi Oscar,

Thank You for the review! Comments inline.

> - To introduce the reader to the topic, maybe you should mention already in the abstract that UDTPL is used for T38 fax transmission.

I suggest something like:

"Abstract

   This document specifies how the UDP Transport Layer (UDPTL) protocol,
   the predominant transport protocol for T.38 fax, 
   can be transported over the Datagram Transport Layer Security (DTLS)
   protocol, how the usage of UDPTL over DTLS is indicated in the
   Session Description Protocol (SDP), and how UDPTL over DTLS is
   negotiated in a session established using the Session Initiation
   Protocol (SIP)."

> - Remove the topmost row "Protocol" in Table 1 and Table 2 or somehow indicate that is a header.

I can remove it.

>  If you decide to change it, then make sure to change all occurrences in the document.

RFC 5763 uses "DTLS association" terminology, so I would suggest we keep it.

> - To me "DTLS over UDP" sounds better than "DTLS over the UDP"

Correct. I tried to remove the "the: s" earlier, but it seems like I missed this one :)

> - The third bullet "If the endpoint supports ..." implies that a fingerprint has to be included also in the case when the endpoint certificate is not self signed, which is unnecessary. Is this what…

We can never be sure that the remote UE has certificate of the certification authority which signed the certificated used by the local UE. Thus, a=fingerprint should always be provided. 

I suggest that we keep the existing text.

>   Instead of leaving the timer out of scope you do could do the same way as in RFC 5764, Section 5.2 and use the UDP maximum segment lifetime (MSL).

We did take a look at 5764, but I haven't managed to find a definition for MSL when used with UDP. We'll look into it.

> - The title should be changed from "Example" to "Examples"

We'll change it as suggested.

> Appendix A.1
>
> - I don't see why you think it's important to add SIP Identity (RFC4474) to the example. In my opinion it just makes the example 
> longer and does not have much to with the main content of the document. I would suggest to remove it and instead add a sentence 
> saying that it is possible to combine the message flow in the example with SIP Identity. Also I think it is questionable how much security 
> SIP Identity provides when it is only used in one of the directions.
>

We can remove it, and add a statement, as suggested.

> - The STUN connectivity check described in Section 4.2.2 is missing from the message flow in Figure 1. The same is true for Figure 6 in A.3.

Will look into that.

> - The description of the individual message is incomplete ("Message (1):").

I don't think it's incomplete (note that there is a page-break), but I'll double check.
 
> - Change "indicates" to "contains" in the sentence "The SDP fingerprint attribute in the SDP offer indicates". The same sentence occurs in three more places in the appendix.

We'll fix as suggested.

> - In the description of message 4, remove "the" in the sentence  "...from the Alice's certificate... "

We'll fix as suggested.

>    association and Bob acts as the active endpoint of DTLS association.

We'll fix as suggested.

>     SDP offer included in the SIP re-INVITE request shown in Figure 7.

We'll fix as suggested.

Thanks!

Regards,

Christer