Subject: [MMUSIC] WGLC for draft-ietf-mmusic-udptl-dtls-06

From: Flemming Andreasen <[email-masked]>
Date: Tue, 25 Mar 2014 16:24:33 -0400

This is to announce a 2 week Working Group Last Call for

     draft-ietf-mmusic-udptl-dtls-06

as Proposed Standard. Please review and provide any comments you may 
have on the document by April 8, 2014. Comments should be sent to the 
document authors and the MMUSIC WG list. If you review the document but 
do not have any comments, please send a note to that effect as well.

Thanks

        Flemming

Draft info:

This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

         Title           : UDP Transport Layer (UDPTL) over Datagram Transport Layer Security (DTLS)
         Authors         : Christer Holmberg
                           Ivo Sedlacek
                           Gonzalo Salgueiro
	Filename        : draft-ietf-mmusic-udptl-dtls-06.txt
	Pages           : 23
	Date            : 2014-03-25

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

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-udptl-dtls/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mmusic-udptl-dtls-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-udptl-dtls-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "David Hanes (dhanes)" <[email-masked]>
Date: Wed, 26 Mar 2014 03:00:14 +0000

I provided earlier comments on this draft and went ahead and reviewed it again. I do not have any additional comments and I fully support this draft moving forward as a proposed standard.

-David

From: "Flemming Andreasen (fandreas)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 25, 2014 at 4:24 PM
To: mmusic <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [MMUSIC] WGLC for draft-ietf-mmusic-udptl-dtls-06

as Proposed Standard. Please review and provide any comments you may have on the document by April 8, 2014. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document but do not have any comments, please send a note to that effect as well.

Thanks

       Flemming

Draft info:

Abstract:

---

From: "Adam Gensler (agensler)" <[email-masked]>
Date: Wed, 26 Mar 2014 14:42:46 +0000

I've reviewed this latest draft and have no comments.

Best regards,
Adam

From: mmusic [mailto:[email-masked]] On Behalf Of Flemming Andreasen
Sent: 25 March 2014 22:25
To: mmusic
Cc: [email-masked]<mailto:[email-masked]>
Subject: [MMUSIC] WGLC for draft-ietf-mmusic-udptl-dtls-06

Thanks

       Flemming

Draft info:

                          Ivo Sedlacek

                          Gonzalo Salgueiro

        Pages           : 23

        Date            : 2014-03-25

Abstract:

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Mar 2014 12:03:19 -0400

Here are my comments based on a quick review of this draft:

Section 4.5:

nit: s/are unchanged are unchanged/are unchanged/

If a new DTLS association is to be established, is it well defined when 
to cut over to it? ISTM that some procedures are required here to ensure 
that data isn't lost, or replicated.

Section A.2, Figure 3:

This shows the entire DTLS handshake taking place before the UAS sends 
*any* sip response. I assume this is only for convenience, and isn't 
intended to imply that this is how it should be done. In reality, it is 
likely that *some* sip response will be sent and received before the 
DTLS handshake completes - maybe before it starts.

It would be helpful to comment on this.

Of the above, the one about cut over could call for significant new 
content. But I expect there to be discussion of that one first. The 
others are editorial.

Otherwise this draft seems ready to me.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Mar 2014 18:28:52 +0000

Hi,

>nit: s/are unchanged are unchanged/are unchanged/

I'll fix that.

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

>that data isn't lost, or replicated.

I don't think we can define any exact procedures for that. DTLS-SRTP doesn't define any exact procedures either. RFC 5763 only says:

  "Once the new session keys are established, the session can switch to using these and abandon the old keys."

...and I don't think we can say much more.

In addition, I assume there are procedures on the fax application layer for avoiding lost data.

Also, I think it will be rare that the keys and/or transport parameters change during a fax transmission. Or, if they do, perhaps a fax transmission failure is acceptable?

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

> It would be helpful to comment on this.

Flemming had a similar comment. We addressed that by adding the following paragraph to the description text for Message (4):

      "Note that, unlike in this example, it is not necessary to wait for
      the DTLS handshake to finish before the SDP answer is sent.  If
      Bob has sent the SIP 200 (OK) response and later detects that the
      certificate fingerprints do not match, he will terminate the
      session."

Regards,

Christer

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 27 Mar 2014 18:36:19 +0000

>> nit: s/are unchanged are unchanged/are unchanged/

Data loss prevention/recovery mechanisms are in place at the fax layer.

-G

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Mar 2014 11:38:58 -0400

> Data loss prevention/recovery mechanisms are in place at the fax layer.

The case I'm talking about is: A new O/A results in establishing a new 
connection, replacing a prior one. At some point during that process 
both the old and new connections are usable. Then, at some point the 
sender stops sending to the old connection and starts sending to the new 
one.

For the receiver to get all the data, it must keep reading from the old 
one until it has received the last packet sent there, and must start 
reading on the new connection soon enough to get the first data sent 
there. And there is a possibility that the packets won't arrive in the 
order sent, so ceasing to read from the new one once something has been 
received from the old one could cause something to be lost. (Or course 
these aren't reliable protocols, so something could be lost in the 
network too.)

Are you saying that the fax layer is sufficient to deal with this? (I 
haven't looked at it.)

I realize that this problem isn't unique here - it applies any time O/A 
results in a change to the media path. I've wondered about it for a long 
time, but have assumed it has typically been considered acceptable to 
get a "glitch" in an audio or video stream in such a case. But it is 
less acceptable for fax.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Mar 2014 18:25:36 +0000

Hi,

> sender stops sending to the old connection and starts sending to the new

Yes.

> Are you saying that the fax layer is sufficient to deal with this? (I

Yes.

I don't think the receiver should cease to read from the new one if it receives something from the old one.

If it helps, we could add a sentence saying that the receiver needs to be prepared to receive data on both the new and old connections, as long as they are both alive.

> get a "glitch" in an audio or video stream in such a case. But it is

It is not even introduced by this draft, as FoIP using SDP O/A has been around for many years.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Mar 2014 16:16:01 -0400

I've had my say on this. I'll be satisfied with whatever you decide to 
do about it, including nothing.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 29 Mar 2014 09:46:48 +0000

Thanks, Paul!

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Paul Kyzivat <[email-masked]> wrote:

        Thanks,
        Paul