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

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2017 12:19:00 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-mmusic-dtls-sdp-31: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/

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

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.

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?

---

From: Roman Shpount <[email-masked]>
Date: Fri, 27 Oct 2017 15:31:40 -0400

Eric,

I wanted to address one of your comments:

> What is the rationale for this rule?

This is informational and simply restates the rule from
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-13#section-8.5 ,
which says:

In particular, if an agent receives a mid-dialog re-INVITE that contains no
offer, it MUST restart ICE for each media stream and go through the process
of gathering new candidates.

Regards,
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2017 12:47:32 -0700

It would be useful if you noted that it restated the rule

On Fri, Oct 27, 2017 at 12:31 PM, Roman Shpount <[email-masked]> wrote:

> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-13#section-8.5
> , which says:
>
> In particular, if an agent receives a mid-dialog re-INVITE that contains
> no offer, it MUST restart ICE for each media stream and go through the
> process of gathering new candidates.
>
>
> Regards,
> _____________
> Roman Shpount
>
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 27 Oct 2017 15:58:17 -0400

Hi Eric,

I thought this already does.Complete text from this paragarpah is:

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

The second sentence is supposed to indicate that we are restating the rule
from [I-D.ietf-mmusic-ice-sip-sdp].

Please let us know if this is unclear or needs to be reworded.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 29 Oct 2017 20:06:50 +0000

Hi,

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

----

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 29 Oct 2017 13:55:19 -0700

Yeah, that seems OK

-Ekr

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 29 Oct 2017 21:17:18 +0000

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

Yeah, that seems OK

-Ekr

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

-----

----

OLD:

NEW:

----

Regards,

Christer