Subject: [MMUSIC] Bundle - Last Chance to comment on changes in Bundle (draft-ietf-mmusic-sdp-bundle-negotiation-42)

From: Flemming Andreasen <[email-masked]>
Date: Wed, 29 Nov 2017 11:36:19 -0500

Greetings

At this point, there are no further outstanding technical issues in 
bundle and we believe the authors have addressed all the editorial 
comments that can reasonably be addressed. We are planning to move ahead 
with publication request of

https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-42

unless we hear any objections from anybody, and hence this will be your 
last chance to comment on the recent changes.

If you have any comments (incl. indications of "reviewed and ready"), 
please send those to the MMUSIC list and document authors no later than 
Friday, December 8, 2017.

Thanks

-- Flemming (as MMUSIC co-chair)

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Nov 2017 16:39:05 -0500

> last chance to comment on the recent changes.

I really wanted to be satisfied with this. But I still have a problem 
with the language.

Christer has definitely improved things by introducing the notion of 
"suggested offerer BUNDLE address". But this terminology is only used in 
passing in the text, and lacks a definition. And "Offerer BUNDLE 
address" is still the term that is defined and used. And it is used in 
ways that conflict with its definition.

I propose that the terminology be revised, and then some minor tweaks 
the the other text be updated to use it. I think the following 
definitions will work:

    Suggested Offerer BUNDLE address: the address:port combination in the
    "m=" section identified by the Offerer BUNDLE-tag.

    Offerer BUNDLE address: the address:port combination in the "m="
    section of the offer that corresponds (per [RFC3264]) to the "m="
    section of the answer that is identified  by the Answerer BUNDLE-tag.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 30 Nov 2017 12:33:04 +0000

Hi,

>    section of the answer that is identified  by the Answerer BUNDLE-tag.

I don¹t think that works as suggested.

³suggested² is only used when a new offerer BUNDLE address is to be
negotiated. In subsequent offers, once the BUNDLE group has been created,
it is not ³suggested² anymore:

"When an offerer generates a subsequent offer (i.e., a BUNDLE group
   has previously been negotiated), it MUST assign the previously
   selected offer BUNDLE address²

So, we can fore sure say that the offerer BUNDLE address is selected by
the answerer, but when used in subsequent offers it has nothing to do with
the answerer BUNDLE-tag.

Perhaps something like:

	Offerer BUNDLE address: once a suggested offerer BUNDLE address has been
selected by the answerer, the address:port combination used by the offerer
for sending and receiving media.

	Suggested Offerer BUNDLE address: before an offerer BUNDLE address has
been selected by the answerer, or when the offerer wants to change a
previously selected offerer BUNDLE address, the address:port combination
	that the offerer wants to use for sending and receiving media. While
suggested by the offerer, the selection of the offerer BUNDLE address is
done by the answerer.

Do we really need to talk about the BUNDLE-tags in the definition section?
How the BUNDLE addresses are identified is described in the spec.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Nov 2017 11:30:39 -0500

> it is not ³suggested² anymore:

We could argue about whether it is a suggestion when a new offer is sent 
that doesn't change the address. (It can be considered a degenerate 
suggestion, where the only alternative is refusal.)

But it isn't worth picking over. I think your proposal below will work.

> the answerer, but when used in subsequent offers it has nothing to do with

Identifying it by the answerer bundle tag will still work. Just 
different ways of thinking of it.

> How the BUNDLE addresses are identified is described in the spec.

Perhaps not. I was trying to get things nailed down in the definitions. 
Certainly the way I have been thinking of it is as I wrote it. But the 
way you have proposed also seems to work as long as the supporting text 
is consistent.

My main concern was that Offerer BUNDLE address is currently used in the 
text in ways that are inconsistent with the current definition.

	Thanks,
	Paul