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

[Christer Holmberg <[e-mail]>]

Hi,

>Here are my comments based on a quick review of this draft:
>
>Section 4.5:
>
>nit: s/are unchanged are unchanged/are unchanged/

I'll fix that.


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


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

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?


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


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

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