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

Christer Holmberg <> Fri, 20 December 2013 07:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E9F521AF708 for <>; Thu, 19 Dec 2013 23:59:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.251
X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kVjJyfDvJCPb for <>; Thu, 19 Dec 2013 23:59:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4E00E1AF700 for <>; Thu, 19 Dec 2013 23:59:32 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-9e-52b3f8e1d957
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id A5.56.23787.1E8F3B25; Fri, 20 Dec 2013 08:59:29 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0347.000; Fri, 20 Dec 2013 08:59:11 +0100
From: Christer Holmberg <>
To: Oscar Ohlsson <>, "" <>
Thread-Topic: Review of draft-ietf-mmusic-udptl-dtls-02
Thread-Index: Ac7793c0Hub88/JyQHOuPWr4QODOFwAMyBYc
Date: Fri, 20 Dec 2013 07:59:11 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvre7DH5uDDLqe6VhMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGe9OBRd81aqYc6CVtYGxSamLkZNDQsBEYvmF4+wQtpjEhXvr 2boYuTiEBA4xSlybtZEJwlnCKHHy6xcgh4ODTcBCovufNkiDiECoRFfXNEYQW1jATOLXg4vs EHFziUWP77FB2EYSs5ZvYQKxWQRUJc4dXMoGMoZXwFfiSR8nSFgIyDy1uYkZxOYU8JPY39EA 1soIdM/3U2vAWpkFxCVuPZnPBHGngMSSPeeZIWxRiZeP/7FC2IoS7U8bGCHqdSQW7P7EBmFr Syxb+BqsnldAUOLkzCcsExhFZyEZOwtJyywkLbOQtCxgZFnFyJ6bmJmTXm64iREY8ge3/Nbd wXjqnMghRmkOFiVx3g9vnYOEBNITS1KzU1MLUovii0pzUosPMTJxcEo1ME6ONduQXbh7yc1Z nOX7uHcaSlpPLCopdaz8m3VSd9o1+dsxBZrvVAuULB6cudbp5b5vdSLXrilLz/9jefSnf8sz Lm3dO+yzKmaYf3IXuPtJ7QiDfrng+iOfn7YmnmcrYTlc97i8derPFft2S3T1nHzW8X7ltJpz CpPai7oPlVe8nJd//kdrsIYSS3FGoqEWc1FxIgDMv5skRwIAAA==
Subject: Re: [MMUSIC] Review of draft-ietf-mmusic-udptl-dtls-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Dec 2013 07:59:44 -0000

Hi Oscar,

Thank You for the review! Comments inline.


> Abstract
> - 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:


   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)."


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

I can remove it.

> - 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 occurrences in the document.

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


> Section 3.1
> - 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 you intended?

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.


> 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).

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.


> Appendix A
> - 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.
> If you remove SIP Identity from the example, then also make sure to change the reference to the example in Section 5.

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


> 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.

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.


> 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.

We'll fix as suggested.

> - 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.

We'll fix as suggested.