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

[Eric Rescorla <[e-mail]>]

On Mon, May 21, 2018 at 12:50 AM, Christer Holmberg <
[e-mail]> wrote:

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

Yes, but it also contradicts the SDP RFC.


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

Ben, Adam? You're the ADs for this.



> >   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.
>
>
> This isn't a technical change. I just didn't see the definition.



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

My point is that this paragraph just is too hard to read. My problem isn't
corresponds, it's
"select" and "selected" together. Can you rewrite it so that it's clearer.
Maybe just indicating
that one is is the offer and one is in the answer?


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

Yes, that's good, but perhaps "in its  answer"

-Ekr



> ---
>
>
>
> Regards,
>
>
>
> Christer
>
>
>