Subject: [MMUSIC] draft-ietf-mmusic-udptl-dtls-03 review

From: Ari Keränen <[email-masked]>
Date: Thu, 30 Jan 2014 16:25:33 +0200

Hi,

I reviewed the UDPTL DTLS draft and overall it seems to be in good 
shape. Please find below a few (mostly editorial) comments to consider.

1.  Introduction

    This was mainly because of the challenges involved with
    physical access to telephony equipment.

s/physical access/malevolent physical access/
(or something else saying that there's an unauthorized accessing for 
making an attack in question)

    This document specifies the transport of UDPTL over DTLS using the
    DTLS record layer "application_data" packets [RFC6347].

"application_data" is actually defined in the TLS RFC (5246) and 6347 
doesn't mention that name (as such) at all. Maybe having both RFCs as 
reference makes sense.

4.2.2.  Latching Control without ICE

    and the passive MUST NOT wait for a STUN answer before sending its

s/passive/passive side/

Moreover, the term "Latching" may not be obvious for everyone. Do you 
mean the same as in draft-ietf-mmusic-latching? A sentence explaining 
this could help or alternatively changing the title to more descriptive one.

4.2.3.  STUN Interaction
    The UA MUST demultiplex packets arriving on the IP address and port
    associated with the DTLS association as follows:

Why is this a MUST? Wouldn't other ways be OK too (say, magic cookie)? 
Maybe s/MUST/can/?

A.3.  Message Flow Of T.38 Fax Replacing Audio Media Stream in An
       Existing Audio-Only Session

    Traditionally, most session with non-secure transport of T.38 fax,
    transported using UDPTL, are established by modifying an ongoing

s/session/sessions/

Cheers,
Ari

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 31 Jan 2014 11:56:36 +0000

Hi Ari,

Thanks for your review! Comments inline.

> s/physical access/malevolent physical access/ (or something else 
> saying that there's an unauthorized accessing for making an attack in
> question)

I will change as suggested.

> doesn't mention that name (as such) at all. Maybe having both RFCs as 

I suggest the following modification:

	"This document specifies the transport of UDPTL over DTLS using the
   	DTLS record layer "application_data" packets [RFC5246] [RFC6347]."

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

>    and the passive MUST NOT wait for a STUN answer before sending its

I will change as suggested.

> this could help or alternatively changing the title to more descriptive one.

I would rather suggest to change the section titles, as following:

4.2.1. NAT Traversal With ICE
4.2.2. NAT Traversal Without ICE

...because, the text doesn't really talk so much about latching per se, but more about the opening of pin holes etc.

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

> Why is this a MUST? Wouldn't other ways be OK too (say, magic cookie)? 

I suggest to add "e.g.", to show that the documented demux mechanism is only one way it can be done.

	"The UA MUST demultiplex packets arriving on the IP address and port
	associated with the DTLS association, e.g. as follows:"

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

>    transported using UDPTL, are established by modifying an ongoing

I will change as suggested.

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

Thanks!

Regards,

Christer

---

From: Ari Keränen <[email-masked]>
Date: Fri, 31 Jan 2014 15:41:02 +0200

Hi Christer,

Looks good, thanks!

Cheers,
Ari