Subject: [MMUSIC] Draft new version: draft-dtls-sdp [was: Eric Rescorla's No Objection on draft-ietf-mmusic-dtls-sdp-31: (with COMMENT)]

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 Oct 2017 06:16:31 +0000

Hi,

I have submitted a new version (-32) of draft-dtls-sdp, which implements the PR that was created to address Ekr’s remaining COMMENTs.

Regards,

Christer

From: Christer Holmberg [mailto:[email-masked]]
Sent: 29 October 2017 23:17
To: Eric Rescorla <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Eric Rescorla's No Objection on draft-ietf-mmusic-dtls-sdp-31: (with COMMENT)

Pull request created:

https://github.com/cdh4u/draft-dtls-sdp/pull/40

Regards,

Christer

From: Eric Rescorla [mailto:[email-masked]]
Sent: 29 October 2017 22:55
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Eric Rescorla's No Objection on draft-ietf-mmusic-dtls-sdp-31: (with COMMENT)

Yeah, that seems OK

-Ekr

On Sun, Oct 29, 2017 at 1:06 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

> S 5.1.
>   media session immediately (see [RFC8122]).  Note that it is
>   permissible to wait until the other side's fingerprint(s) has been
>   received before establishing the connection; however, this may have
>   undesirable latency effects.
>
> I agree that it's permissible, but why would you do this? This does not seem like helpful guidance.

I suggest to remove the sentence.

-----

> S 10.
> Please do something about the "NEW" constructions. I literally had to pull these into ediff to know what
> had changed. That's not useful to people. I'm not a fan of this construction in general, but at minimum you
> need to explain what has changed.

Before the NEW text, there is a description of what has is changed.

----

> S 9.
>   Regardless of the
>   previous existence of a DTLS association, the SDP 'setup' attribute
>   MUST be included according to the rules defined in [RFC4145] and if
>   ICE is used, ICE restart MUST be initiated.
>
> What is the rationale for this rule?

Based on the discussion you had with Roman, we suggest the following modification to make the rationale clear:

OLD:

Regardless of the previous existence of a DTLS association, the SDP 'setup' attribute MUST be included according to the rules defined in [RFC4145] and if ICE is used, ICE restart MUST be initiated.  This is needed in order to support third party call control, as described in [I-D.ietf-mmusic-ice-sip-sdp].

NEW:

Regardless of the previous existence of a DTLS association, the SDP 'setup' attribute MUST be included according to the rules defined in [RFC4145]. Furthermore, if ICE is used, according to the third party call control considerations described in [I-D.ietf-mmusic-ice-sip-sdp], ICE restart MUST be initiated.

----

Regards,

Christer