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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 31 January 2014 11:56 UTC

From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Ari Keränen <ari.keranen@ericsson.com>, "draft-ietf-mmusic-udptl-dtls@tools.ietf.org" <draft-ietf-mmusic-udptl-dtls@tools.ietf.org>
Thread-Topic: draft-ietf-mmusic-udptl-dtls-03 review
Thread-Index: AQHPHcckatfvrQ/Cl0um0naW4oLZXpqeu1cg
Date: Fri, 31 Jan 2014 11:56:36 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D151248@ESESSMB209.ericsson.se>
References: <52EA60DD.9090402@ericsson.com>
In-Reply-To: <52EA60DD.9090402@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] draft-ietf-mmusic-udptl-dtls-03 review
Precedence: list

Hi Ari,

Thanks for your review! Comments inline.

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

I will change as suggested.

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

I suggest the following modification:

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


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

> 4.2.2.  Latching Control without ICE
>
>    and the passive MUST NOT wait for a STUN answer before sending its
>
> s/passive/passive side/

I will change as suggested.

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

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.

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

> 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/?

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

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

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

I will change as suggested.

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

Thanks!

Regards,

Christer

[MMUSIC] draft-ietf-mmusic-udptl-dtls-03 review Ari Keränen
Re: [MMUSIC] draft-ietf-mmusic-udptl-dtls-03 revi… Christer Holmberg
Re: [MMUSIC] draft-ietf-mmusic-udptl-dtls-03 revi… Ari Keränen