Subject: Re: [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mmusic-sdp-bundle-negotiation-49: (with DISCUSS and COMMENT) - DISCUSS

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Apr 2018 07:06:55 +0000

Hi,

Thank You for the review! In this reply I will address the DISCUSSes.

>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>>      When an offerer generates an offer, in which it wants to add a new
>>      bundled "m=" section, the offerer MUST:
>>
>>      o  Assign the offerer BUNDLE address:port (previously selected
>>         [Section 8.3.1] or newly suggested [Section 8.5.1]) to the added
>>         "m=" section; or
>
>IMPORTANT: This doesn't sound right. You can't use the existing
>address:port, because if the peer rejects BUNDLE but accepts the m=
>section then it's broken.

Note that in this case the usage of BUNDLE has already been negotiated.
Then, if the answerer does not accept the new m= section into the BUNDLE
group, it needs to send an offer where it removes it, as described in
section 8.3.3.

---

>>      o  When the BUNDLE transport has been established, ICE connectivity
>>         checks and keep-alives only need to be performed for the BUNDLE
>>         transport, instead of per individual "m=" section within the
>>         BUNDLE group.
>>
>>      o  In an offer, if the offer assigns a unique address:port to one
>>or
>
>IMPORTANT: This does not define how to interact with trickle ICE.

I assume you refer to the usage of port 9 and/or address 0.0.0.0 in
trickle ICE?

I guess we could add a statement saying that, when trickle ICE is used,
the same port 9 and/or 0.0.0.0 combination might be assigned to one or
more bundled m- sections, even though the usage of BUNDLE has not yet been
assigned. However, as far as BUNDLE is concerned, they should be processed
as unique address:port combinations, meaning that answerer e.g., can
remove such m- sections from the BUNDLE group in the answer, that the
answerer needs to select one combination as offerer/answerer bundle
address etc.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Apr 2018 06:43:55 -0700

> group, it needs to send an offer where it removes it, as described in

Well, both of these options correspond to insisting that the m= section be
in
the BUNDLE group. If I just want to suggest it, I would have to provide a
fresh
unique address. Or are you saying that's impossible.

> answerer needs to select one combination as offerer/answerer bundle

That would seem like a reasonable option.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Apr 2018 14:09:09 +0000

Hi,

> Well, both of these options correspond to insisting that the m= section
>be in
> the BUNDLE group. If I just want to suggest it, I would have to provide
>a fresh

Yes.

Previously, when the offerer wanted to add a new m- section to a BUNDLE
group, it had to choice of either assigning a unique address or a
previously negotiated bundle address.

That option was removed as part of task (triggered by WGLC comments etc)
trying to simplifying the procedures. Currently the offerer must either
assign a bundle address (previously negotiated or new suggested) or
indicate it as bundle-only.

---

> That would seem like a reasonable option.

Ok, I will try to come up with some text.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Apr 2018 10:03:16 -0700

> Hi,

That seems like a pretty material change. Was there a call for consensus on
that?

> indicate it as bundle-only.

At minimum this needs to be clearly stated

-Ekr
-

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Apr 2018 18:11:12 +0000

Hi,

>>> be in the BUNDLE group. If I just want to suggest it, I would have to provide
>>> a fresh unique address. Or are you saying that's impossible.
>>>
>> Yes.
>>
> That seems like a pretty material change. Was there a call for consensus on that?

No. But, the suggested changes were indicated on the list, there were pull requests etc, so people were informed about it and had a chance to comment/object.

> At minimum this needs to be clearly stated

I need to modify the section, so I will add text about it.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Apr 2018 11:18:24 -0700

On Tue, Apr 17, 2018 at 11:11 AM, Christer Holmberg <
[email-masked]> wrote:

> No. But, the suggested changes were indicated on the list, there were pull
> requests etc, so people were informed about it and had a chance to
> comment/object.
>

Hmm... Ben, do you think these were properly surfaced to the WG?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Apr 2018 15:23:30 -0700

Hi folks,

This is an attempt to sharpen my point about talking about the
"BUNDLE address:port", when what we really mean is "use the
parameters from the "m=" section". Here's an example where this
creates a real problem. S 8.4 says:

   When an offerer receives an answer, if the answer contains a BUNDLE
   group, the offerer MUST check that any bundled "m=" section in the
   answer was indicated as bundled in the corresponding offer.  If there
   is no mismatch, the offerer MUST use the offerer BUNDLE address:port,
   selected by the answerer [Section 8.3.1], as the address for each
   bundled "m=" section.

Now consider the case where I am doing trickle ICE. The offer will
contain:

   a=group:BUNDLE foo bar
   m=audio 9 RTP/AVP 97
   c=IN IP4 0.0.0.0
   a=rtpmap:97 iLBC/8000
   a=mid:foo

   m=video 9 RTP/AVP 98
   c=IN IP4 0.0.0.0
   a=rtpmap:98 H261/90000
   a=mid:bar

Now, if the answer contains:

   a=group:BUNDLE foo bar

Then the semantics are that we are supposed to use the parameters from
the m=audio line as the parameters for the bundle group. Specifically,
we are supposed to use the ICE candidates that belong to that m=audio
line. But there's no way to get that from this text. Ordinarily, if
each m=section contained a distinct address:port, then you might say
there was an implicit map from address:port to m= section parameters,
but in this case because all the address:port values are the same,
that's not possible, and so this paragraph just doesn't work.  The
right fix is to stop talking about the address:port and instead talk
about the m= section.

   When an offerer receives an answer, if the answer contains a BUNDLE
   group, the offerer MUST check that any bundled "m=" section in the
   answer was indicated as bundled in the corresponding offer.  If there
   is no mismatch, the offerer MUST use the relevant parameters
   [specific text from Suhas's draft needed here] from the
   "m=" section indicated by the BUNDLE tag [again, it would be helpful
   to have a better name here] for each "m=" section which is bundled
   with it.

There are other places where this creates confusion, but this is
a nice clear one.

-Ekr

On Tue, Apr 17, 2018 at 11:18 AM, Eric Rescorla <[email-masked]> wrote:

>> No. But, the suggested changes were indicated on the list, there were
>> pull requests etc, so people were informed about it and had a chance to
>> comment/object.
>>
>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 19 Apr 2018 11:56:12 +0200

MMUSIC chairs, please see request below:

> Hmm... Ben, do you think these were properly surfaced to the WG?

I seem to recall non-trivial discussion about it on list, but I am not in a position to verify it prior to the telechat. 

Chairs/shepherd: Please comment on whether you believe the aforementioned change represents wg consensus.

Thanks!

Ben.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Apr 2018 18:01:04 -0400

See end.

On 4/19/18 5:56 AM, Ben Campbell wrote:
> On Apr 17, 2018, at 8:18 PM, Eric Rescorla <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>>     No. But, the suggested changes were indicated on the list, there
>>     were pull requests etc, so people were informed about it and had a
>>     chance to comment/object.
>>
>>
> I seem to recall non-trivial discussion about it on list, but I am not 
> in a position to verify it prior to the telechat.
> 
> Chairs/shepherd: Please comment on whether you believe the 
> aforementioned change represents wg consensus.

I'm neither, but I'll comment.

Finding suitable terminology here has been a struggle from the 
beginning. I was the instigator of one wholesale change, but it was 
subsequently heavily revised (I think multiple times). Everything has 
been word smithed to work around many people's objections. Through those 
changes I have generally been quiet because I had my say, and each 
change seemed "good enough" to me, though never something that I thought 
was "great". I would be pleased to have something better.

Clearly it is hard to get the wording to be both precise and clear. I 
suspect it might be possible to do better, but I don't know that for 
sure. The only way to verify that seems to be to make the change across 
the document and then review it again. (It never seems to be something 
that can be done adequately via a global search and replace.)

I sympathize with Christer that this seems to be a "fetch a rock" 
exercise. If anything is to be done, I think we should not ask Christer 
to fix it. Rather, I think those who aren't satisfied with the current 
text should create a variant of the whole document and then we can have 
a bake off.

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 22 Apr 2018 11:21:39 -0400

On 4/19/18 5:56 AM, Ben Campbell wrote:
>>     were pull requests etc, so people were informed about it and had
>>     a chance to comment/object.
>>
>>

The change in question was introduced in the -41 version of the 
document, and the author announced both the change as well as the 
updated document (pointing out the change) on the MMUSIC list on 
November 24, 2017, see:

https://www.ietf.org/mail-archive/web/mmusic/current/msg18364.html
https://www.ietf.org/mail-archive/web/mmusic/current/msg18367.html

A few additional updates where made in -42, and on November 28, 2017, we 
announced a final chance for people to comment on the document before we 
would move ahead with the publication request

https://www.ietf.org/mail-archive/web/mmusic/current/msg18373.html

We received only 1 comment back, which was addressed in -43. Both of the 
chairs reviewed this updated document as well.

In summary, the change has clearly been surfaced to the WG and people 
have been given more than one opportunity to comment on it. The comments 
that were provided have been addressed, and hence the resulting document 
represents WG consensus.

Thanks

-- Flemming (as MMUSIC co-chair)

---

From: Ben Campbell <[email-masked]>
Date: Sun, 22 Apr 2018 17:27:29 +0200

Thanks, Flemming!

> On Apr 22, 2018, at 5:21 PM, Flemming Andreasen <[email-masked]> wrote:
> 
> 
> 
> The change in question was introduced in the -41 version of the document, and the author announced both the change as well as the updated document (pointing out the change) on the MMUSIC list on November 24, 2017, see:
> 
> A few additional updates where made in -42, and on November 28, 2017, we announced a final chance for people to comment on the document before we would move ahead with the publication request
> 
> We received only 1 comment back, which was addressed in -43. Both of the chairs reviewed this updated document as well. 
> 
> 
> In summary, the change has clearly been surfaced to the WG and people have been given more than one opportunity to comment on it.  The comments that were provided have been addressed, and hence the resulting document represents WG consensus. 
> 
> Thanks 
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 24 Apr 2018 11:11:56 -0400

On 4/17/18 6:23 PM, Eric Rescorla wrote:
> line. But there's no way to get that from this text.
True, but it's an inherent part of the definition of the BUNDLE-tag as 
described in the preceding sections covering the overall offer/answer 
procedures.

> Ordinarily, if
> that's not possible, and so this paragraph just doesn't work.
Why not ? The BUNDLE-tag in the answer indicates which "m=" section the 
answerer chose and hence you will use the corresponding BUNDLE 
address:port.

> The
I think we are saying the same thing here, but you are just asking for 
the BUNDLE-tag to be called out more explicitly as opposed to focusing 
on the BUNDLE address:port. Is that right ?

Thanks

-- Flemming

> -Ekr
>
>
>
>
>
> On Tue, Apr 17, 2018 at 11:18 AM, Eric Rescorla <[email-masked] 
>     On Tue, Apr 17, 2018 at 11:11 AM, Christer Holmberg
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Hi,
>
>         No. But, the suggested changes were indicated on the list,
>         there were pull requests etc, so people were informed about it
>         and had a chance to comment/object.
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Apr 2018 01:23:39 -0700

> described in the preceding sections covering the overall offer/answer

But this text doesn't say anything about the BUNDLE-tag. It says to select
the address.

> answerer chose and hence you will use the corresponding BUNDLE

But that's not in this text.

> I think we are saying the same thing here, but you are just asking for the
> BUNDLE-tag to be called out more explicitly as opposed to focusing on the
> BUNDLE address:port. Is that right ?
>

Yes, more or less. I'm asking for it to be the primary unit of analysis.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 25 Apr 2018 11:44:37 +0000

Hi,

As it would not be very convenient to talk about “the m= section identified by the BUNDLE-tag”, there has been a suggestion to e.g., talk about “the lead m- section”.

My suggestion would be to talk about “tagged m- section” or “BUNDLE-tagged m- section”. We don’t need to add more fancy words into the document :)

Regards,

Christer

From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 25 April 2018 at 11:23
To: Flemming Andreasen <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[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]>>, "[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 Discuss on draft-ietf-mmusic-sdp-bundle-negotiation-49: (with DISCUSS and COMMENT) - DISCUSS

On Tue, Apr 24, 2018 at 8:11 AM, Flemming Andreasen <[email-masked]<mailto:[email-masked]>> wrote:

   a=group:BUNDLE foo bar
   m=audio 9 RTP/AVP 97
   c=IN IP4 0.0.0.0
   a=rtpmap:97 iLBC/8000
   a=mid:foo

   m=video 9 RTP/AVP 98
   c=IN IP4 0.0.0.0
   a=rtpmap:98 H261/90000
   a=mid:bar

   a=group:BUNDLE foo bar

True, but it's an inherent part of the definition of the BUNDLE-tag as described in the preceding sections covering the overall offer/answer procedures.

But this text doesn't say anything about the BUNDLE-tag. It says to select the address.

Ordinarily, if
Why not ? The BUNDLE-tag in the answer indicates which "m=" section the answerer chose and hence you will use the corresponding BUNDLE address:port.

The

I think we are saying the same thing here, but you are just asking for the BUNDLE-tag to be called out more explicitly as opposed to focusing on the BUNDLE address:port. Is that right ?

-Ekr

Thanks

-- Flemming

-Ekr

On Tue, Apr 17, 2018 at 11:18 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Apr 17, 2018 at 11:11 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

-Ekr

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Apr 2018 04:54:10 -0700

Let's do "tagged" b/c BUNDLE-tagged is long

-Ekr

On Wed, Apr 25, 2018 at 4:44 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> As it would not be very convenient to talk about “the m= section
> identified by the BUNDLE-tag”, there has been a suggestion to e.g., talk
> about “the lead m- section”.
>
> My suggestion would be to talk about “tagged m- section” or “BUNDLE-tagged
> m- section”. We don’t need to add more fancy words into the document :)
>
> Regards,
>
> Christer
>
> From: Eric Rescorla <[email-masked]>
> To: Flemming Andreasen <[email-masked]>
> Cc: Christer Holmberg <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
>> the BUNDLE-tag to be called out more explicitly as opposed to focusing on
>> the BUNDLE address:port. Is that right ?
>>
>