Re: [MMUSIC] Eric Rescorla's No Objection on draft-ietf-mmusic-sdp-bundle-negotiation-51: (with COMMENT)

[Christer Holmberg <[e-mail]>]

Hi,

>This is really vastly better. Thanks for making the changes.

Thank You! :)

>I have made a few notes of things that I still think are problematic, but I
>am clearing my DISCUSS.
>
>   o  Initial offer: The first offer, within an SDP session (e.g. a SIP
>      dialog when the Session Initiation Protocol (SIP) [RFC3261] is
>
> This appears still not to be resolved. Here is the 3264 definition "
> Protocol operation begins when one agent sends an initial offer to
> another agent. An offer is initial if it is outside of any context
> that may have already been established through the higher layer
> protocol." I'm not making this part of my DISCUSS, but I think it's
> very confusing and I would strongly urge the AD to address it.

This is based on the structure that MMUSIC has previously agreed on, and is used in many drafts. The text does explain what “initial offer” means in the context of the document.

I am happy to re-visit that discussion in MMUSIC on a generic level, but as far as this document is concerned I think we shall keep the currently agreed structure.

---

>   The "c=" line nettype value [RFC4566] associated with a bundled "m="
>   section MUST be 'IN'.
>
> It seems like you should define bundled "m=" section.

Section 2 contains the definition.

> I believe it's one that appears in a bundle tag?

It applies to all sections suggested to be in the BUNDLE group.

If you think it should only apply to the tagged section (similar to most other properties), I can do that change.

---

>   o  In the initial offerer, the offerer MUST NOT include IDENTICAL and
>      TRANSPORT multiplexing category SDP attributes (BUNDLE attributes)
>
> initial offer

Will fix.

---

>      TRANSPORT multiplexing category SDP attributes (BUNDLE attributes)
>      in bundle-only "m=" sections.  The offerer MUST included such
>      attributes in all other bundled "m=" sections.  In the initial
>
> MUST include

Will fix.

---

>   [Section 7.3.1] as the answerer tagged "m=" section.  In the answer
>   the answerer BUNDLE-tag indicates the answerer tagged "m=" section.
>
> I'm having trouble reading this paragraph. How do you select an m= section that correspond to the selected m= section.

The n:th m- line in an answer corresponds to the n:th m- line in the offer.

There was some discussion about the terminology, and “corresponds” was the outcome.

I did find a small nit in the text, though:

s/”section in that”/”section that”

---

>   When an answerer wants to reject a bundled "m=" section in an answer,
>   it MUST first check the following criterium:
>
> criterion would be more standard English. criterium generally refers to a bike race

Ok :)

I THINK Adam requested to have criterium, but I don’t find his e-mail, so maybe I remember wrong. I will change to criterion.

---

>   add a bundled "m=" section to a previously negotiated BUNDLE group,
>   the offerer follows the procedures in [Section 7.5].  The offerer
>   either picks the added "m=" section, or an "m=" section previously
>
> You should make clear that it's not possible to have an added m= section that the peer can take as bundled or not.

What about adding the following note:

“NOTE: As described in [Section 7.3.3], the answerer can not move the added “m=” section out of the BUNDLE group in the associated answer.
If the answer wants to move the “m=” section out of the BUNDLE group, it will have to first accept it into the BUNDLE group in the answer, and
then send a subsequent offer where the “m=” section is moved out of the BUNDLE group [Section 7.5.2].”

---

Regards,

Christer