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

From: Eric Rescorla <[email-masked]>
Date: Sat, 19 May 2018 13:18:22 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-mmusic-sdp-bundle-negotiation-51: 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-sdp-bundle-negotiation/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3382

This is really vastly better. Thanks for making the changes. I have
made a few notes of things that I still think are problematic, but I
am clearing my DISCUSS.

IMPORTANT
S 7.3.5.
>      a zero port value to, the video "m=" section.
>   
>      SDP Answer
>   
>        v=0
>        o=bob 2808844564 2808844564 IN IP6 2001:db8::1

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.

S 9.3.1.2.
>   
>   9.3.1.2.  Generating the SDP Answer
>   
>      When an answerer generates an answer, if the answerer supports RTP-
>      based media, and if a bundled "m=" section in the corresponding offer
>      contained an SDP 'rtcp-mux' attribute, the answerer MUST enable usage

This does not define how to interact with trickle ICE.

COMMENTS

>   
>    Negotiating Media Multiplexing Using the Session Description Protocol
>                                    (SDP)
>               draft-ietf-mmusic-sdp-bundle-negotiation-51.txt
>   
>   Abstract

This document is quite a bit improved from when I read it before, but
it's still very confusing. The primary problem here is the repeated
use of "address;port" as synechdoche for the m= section which is the
"head" of the BUNDLE group (i.e., that which is indicated by the
BUNDLE-tag). That's not what's going on and it's misplaced
concreteness. I would invent some new term ("head" is actually not
bad) and then use it throughout for this concept.

S 1.2.
>      transport) for sending and receiving media (bundled media) described
>      by multiple SDP media descriptions ("m=" sections).  The address:port
>      combination used by an endpoint for sending and receiving bundled
>      media is referred to as the BUNDLE address:port.  The set of SDP
>      attributes that are applied to each "m=" section within a BUNDLE
>      group is referred to as BUNDLE attributes.  The same BUNDLE transport

Nit: "pair"?

S 1.2.
>      group is referred to as BUNDLE attributes.  The same BUNDLE transport
>      is used for sending and receiving bundled media, which means that the
>      symmetric Real-time Transport Protocol (RTP) mechanism [RFC4961] is
>      always used for RTP-based bundled media.
>   
>      This specification defines a new SDP Grouping Framework [RFC5888]

Why is one of these called "address" and the other "address:port"?

S 1.2.
>      Interactive Connectivity Establishment (ICE)
>      [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group.
>   
>      A given BUNDLE address:port MUST only be associated with a single
>      BUNDLE group.  If an SDP offer or answer contains multiple BUNDLE
>      groups, the procedures in this specification apply to each group

1. Bundle lets you have multiple SDP m= sections on a single 5-tuple
2. The underling mechanism here is that you put those m= sections in
the same BUNDLE group
3. In order to facilitate demuxing, we define a new RTP extension for
MID.
4. It is sometimes desirable to say that an m= section should only be
negotiated if it can be bundled. This is done with port=0 and a
=bundle-only.

S 1.2.
>      Interactive Connectivity Establishment (ICE)
>      [I-D.ietf-ice-rfc5245bis] candidates for the whole BUNDLE group.
>   
>      A given BUNDLE address:port MUST only be associated with a single
>      BUNDLE group.  If an SDP offer or answer contains multiple BUNDLE
>      groups, the procedures in this specification apply to each group

This section is kind of a laundry list. I think it would be helpful to
break it out conceptually. Specifically.

1.
2.
3.

S 1.3.
>         SDES header extension that can be used to associate RTP streams
>         with "m=" sections.
>   
>      o  The specification updates [RFC7941], by adding an exception, for
>         the MID RTP header extension, to the requirement regarding
>         protection of an SDES RTP header extension carrying an SDES item

Was this intended to be a bullet?

S 2.
>   
>      o  BUNDLE attributes: IDENTICAL and TRANSPORT multiplexing category
>         SDP attributes.  Once a BUNDLE group has been created, the
>         attribute values apply to each bundled "m=" section within the
>         BUNDLE group.
>   

This is a very idiosyncratic definition, because it's *not* the first
offer in the session, but the one where the BUNDLE group is
introduced. Given that 3264 has a different meaning for this same
term, and the difference is critical, I would strongly urge you to
pick a different term.

S 2.
>      o  Bundle-only "m=" section: A bundled "m=" section that contains an
>         SDP 'bundle-only' attribute.
>   
>      o  Bundled media: All media associated with a given BUNDLE group.
>   
>      o  Initial offer: The first offer, within an SDP session (e.g. a SIP

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.

S 2.
>         BUNDLE group is created once the answerer sends the initial
>         answer.
>   
>      o  Subsequent offer: An offer which contains a BUNDLE group that has
>         been created as part of a previous offer/answer exchange.
>   

How about "is part of" instead of "associated with"

S 2.
>         been created as part of a previous offer/answer exchange.
>   
>      o  Subsequent answer: An answer to a subsequent offer.
>   
>      o  Identification-tag: A unique token value that is used to identify
>         an "m=" section.  The SDP 'mid' attribute [RFC5888] in an "m="

Again "part of"

S 5.
>      a semantics value [RFC5888] of "BUNDLE".  An identification-tag is
>      assigned to each bundled "m=" section, and each identification-tag is
>      listed in the SDP 'group:BUNDLE' attribute identification-tag list.
>      Each "m=" section whose identification-tag is listed in the
>      identification-tag list is associated with a given BUNDLE group.
>   

I would put some of this text up before the attribute definition to
explain why the attribute exists.

S 7.
>      rejected by the answerer, the previously negotiated addresses:ports,
>      SDP parameters and characteristics (including those associated with a
>      BUNDLE group) apply.  Hence, if an offerer generates an offer in
>      order to negotiate a BUNDLE group, and the answerer rejects the
>      offer, the BUNDLE group is not created.
>   

Multiplexing?

S 7.
>      "m=" line proto value assigned to a bundled "m=" section.  Section 9
>      defines additional considerations for RTP based media.  Section 6
>      defines additional considerations for the usage of the SDP 'bundle-
>      only' attribute.  Section 10 defines additional considerations for
>      the usage of Interactive Connectivity Establishment (ICE)
>      [I-D.ietf-ice-rfc5245bis] mechanism.

Something bad happened here with your editor.

S 7.
>      the usage of Interactive Connectivity Establishment (ICE)
>      [I-D.ietf-ice-rfc5245bis] mechanism.
>   
>      Offers and answers can contain multiple BUNDLE groups.  The
>      procedures in this section apply independently to a given BUNDLE
>      group.

This is pretty opaque. It's not that the address:port pair have been
selected but rather that BUNDLE has been negotiated for that m=
section (though of course the address:port being selected is a side
effect of this).

S 7.1.1.
>      attribute values have been assigned to each bundled "m=" section.
>   
>   7.1.1.  Connection Data (c=)
>   
>      The "c=" line nettype value [RFC4566] associated with a bundled "m="
>      section MUST be 'IN'.

It seems like you should define bundled "m=" section. I believe it's
one that appears in a bundle tag?

S 7.1.1.
>   
>   7.1.1.  Connection Data (c=)
>   
>      The "c=" line nettype value [RFC4566] associated with a bundled "m="
>      section MUST be 'IN'.
>   

Huh? This is section 8.1.

This whole paragraph is a mess. I would say

"One consequence of these rules is that because SDP attributes which
are appropriate only to some other m= section may appear in the m=
section indicated by the BUNDLE-tag. For instance, the BUNDLE-tag may
indicate a data channel but contain the 'rtcp-mux' attribute because
that applies to an RTP m= section that is part of the BUNDLE group"

S 7.1.2.
>      with each "m=" section.
>   
>      NOTE: Extensions to this specification can specify usage of the
>      BUNDLE mechanism for other nettype and addrtype values than the ones
>      listed above.
>   

This sentence is ungrammatical. "In order to negotiate a BUNDLE group
in an initial offer, the offerer MUST"

S 7.1.3.
>   
>      An offerer and answerer MUST include SDP attributes in every bundled
>      "m=" section where applicable, following the normal offer/answer
>      procedures for each attribute, with the following exceptions:
>   
>      o  In the initial offerer, the offerer MUST NOT include IDENTICAL and

initial offer

S 7.1.3.
>      "m=" section where applicable, following the normal offer/answer
>      procedures for each attribute, with the following exceptions:
>   
>      o  In the initial offerer, the offerer MUST NOT include IDENTICAL and
>         TRANSPORT multiplexing category SDP attributes (BUNDLE attributes)
>         in bundle-only "m=" sections.  The offerer MUST included such

MUST include

S 7.1.3.
>         attributes in all other bundled "m=" sections.  In the initial
>         offer each bundled "m=" line can contain a different set of BUNDLE
>         attributes, and attribute values.  Once the offerer tagged "m="
>         section has been selected, the BUNDLE attributes contained in the
>         offerer tagged "m=" section will apply to each bundled "m="
>         section within the BUNDLE group.

I would reorder these, because the zero port is the main semantic.

S 7.1.3.
>         tagged "m=" section).  The offerer and answerer MUST NOT include
>         such attributes in any other bundled "m=" section.  The BUNDLE
>         attributes contained in the tagged "m=" section will apply to each
>         bundled "m=" section within the BUNDLE group.
>   
>      o  In an offer (initial or subsequent), or in an answer (initial or

Why is this an "If"? There are only two choices: "unique" and "zero".
Just put this graf up before the discussion of bundle-only and you can
remove the conditional

S 7.2.
>      within the BUNDLE group does describe RTP-based media).
>   
>   7.2.  Generating the Initial SDP Offer
>   
>      When an offerer generates an initial offer, in order to negotiate a
>      BUNDLE group, it MUST:

I would say "believes" rather than "assumes"

S 7.2.
>      within the negotiated BUNDLE group, the offerer MUST:
>   
>      o  Include an SDP 'bundle-only' attribute [Section 7.2.1] in the "m="
>         section; and
>   
>      o  Assign a zero port value to the "m=" section.

Line breaks between the m= sections would help here.

S 7.2.
>      section, but does not include an SDP 'bundle-only' attribute in the
>      "m=" section, it is an indication that the offerer wants to disable
>      the "m=" section [Section 7.5.3].
>   
>      [Section 7.2.2] and [Section 17.1] show an example of an initial
>      offer.

Comma not needed here. Also, this negative phrasing is hard to follow.
I would say "MUST only ... if" here and below

S 7.2.1.
>      In the initial offer, the bundled "m=" section indicated by the
>      offerer BUNDLE-tag is the suggested offerer tagged "m=" section.  The
>      address:port combination associated with the "m=" section will be
>      used by the offerer for sending and receiving bundled media if the
>      answerer selects the "m=" section as the offerer tagged "m=" section
>      [Section 7.3.1].  In addition, if the answerer selects the "m="

This bullet is unnecessary as it immediately follows from the
preoceeding bukllet.

S 7.2.1.
>      section as the offerer tagged "m=" section, the BUNDLE attributes
>      included in the "m=" section will be applied to each "m=" section
>      within the negotiated BUNDLE group.
>   
>      The offerer MUST NOT suggest a bundle-only "m=" section as the
>      offerer tagged "m=" section.

This isn't right, because each BUNDLE group has its own address:port,
so instead "For each BUNDLE group" contained in the offer.

More importantly, it's not the address:port that the answerer chooses,
but rather the m= section. I.e.,

o Determine the first m= section in the BUNDLE group which will be
BUNDLEd in the answer
o Select an answerer BUNDLE address:port

S 7.3.
>        a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
>   
>   7.3.  Generating the SDP Answer
>   
>      When an answerer generates an answer (initial or subsequent) that
>      contains a BUNDLE group the following general SDP grouping framework

Again, this isn't selecting the address:port but rather the m=section

S 7.3.
>         section using the procedures in Section 7.3.1.  In case of a
>         subsequent answer, the offerer tagged "m=" section is indicated in
>         the corresponding subsequent offer, and MUST NOT be changed by the
>         answerer; and
>   
>      o  Select the answerer tagged "m=" section [Section 7.3.2]; and

This repeats text in S 8.3.

S 7.3.
>   
>      o  Include SDP attributes in the bundled "m=" sections following the
>         rules in [Section 7.1.3]; and
>   
>      o  Include an SDP 'group:BUNDLE' attribute in the answer; and
>   

This text is baffling. As far as I can see, the first condition is
"don't pick it as the head m= section if you intend to move it out".
The second is some entirely different case. Can you rewrite it so it
makes sense.

S 7.3.
>      group, it MUST:
>   
>      o  Move the "m=" section out of the BUNDLE group [Section 7.3.3]; or
>   
>      o  Reject the "m=" section [Section 7.3.4].
>   

No comma

S 7.3.1.
>      value, but the "m=" section does not contain an SDP 'bundle-only'
>      attribute, it is an indication that the offerer wants to disable the
>      "m=" section [Section 7.5.3].
>   
>   7.3.1.  Answerer Selection of Offerer tagged 'm=' section
>   

This is the third time you have said this. If you want to say it here,
say "Because ..., if"

S 7.3.1.
>      o  The answerer will not reject the "m=" section [Section 7.3.4]; and
>   
>      o  The "m=" section does not contain a zero port value.
>   
>      If all of the criteria above are fulfilled, the answerer MUST select
>      the "m=" section as the offerer tagged "m=" section.

Same comment here as above. These are entirely different conditions.

S 7.3.1.
>      o  The "m=" section does not contain a zero port value.
>   
>      If all of the criteria above are fulfilled, the answerer MUST select
>      the "m=" section as the offerer tagged "m=" section.
>   
>      If one or more of the criteria are not fulfilled, the answerer MUST

"criteria... are"

S 7.3.1.
>      indicated by that identification-tag.  If there are no more
>      identification-tags in the identification-tag list, the answerer MUST
>      NOT create the BUNDLE group.  Unless the answerer rejects the whole
>      offer, the answerer MUST apply the answerer procedures for moving an
>      "m=" section out of a BUNDLE group [Section 7.3.3] or rejecting an
>      "m=" section within a BUNDLE group [Section 7.3.4] to every bundled

No comma

S 7.3.2.
>   7.3.2.  Answerer Selection of Answerer tagged 'm=' section
>   
>      The answerer MUST select the "m=" section in that corresponds to the
>      selected offerer tagged "m=" section in the corresponding offer
>      [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.

S 7.3.3.
>      has been negotiated, a bundled "m=" section can not be moved out of
>      the BUNDLE group in an answer.  Instead an offer is needed.
>   
>      When the answerer generates an answer, in which it moves a bundled
>      "m=" section out of a BUNDLE group, the answerer:
>   

Please put line breaks in between m= sections here too

S 7.3.3.
>   
>      o  MUST include any applicable SDP attribute in the "m=" section,
>         using the normal offer/answer procedures for the each Attributes;
>         and
>   
>      o  MUST NOT place the identification-tag associated with the "m="

address:port, again. It's the m=section that's relevant.

S 7.3.3.
>         list associated with the BUNDLE group.
>   
>      o  MUST NOT include an SDP 'bundle-only' attribute to the "m="
>         section; and
>   
>      Because an answerer is not allowed to move an "m=" section from one

"each" -> "an given"

S 7.3.4.
>      another BUNDLE group [Section 7.5.1].
>   
>   7.3.4.  Rejecting a Media Description in a BUNDLE Group
>   
>      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

S 7.3.4.
>         the procedures in [RFC3264]; and
>   
>      o  MUST NOT place the identification-tag associated with the "m="
>         section in the SDP 'group:BUNDLE' attribute identification-tag
>         list associated with the BUNDLE group; and
>   

Again it would make more sense to describe this as suggesting a new m=
section.

S 7.5.
>   
>      o  Pick one bundled "m=" section as the offerer tagged "m=" section.
>         The offerer can either pick the "m=" section that was previously
>         selected by the answerer as the offerer tagged "m=" section, or
>         pick another bundled "m=" section within the BUNDLE group; and
>   

Are you sure disable -> port 0, as opposed to "inactive"

S 7.5.1.
>   
>   7.5.1.  Adding a Media Description to a BUNDLE group
>   
>      When an offerer generates a subsequent offer, in which it wants to
>      add a bundled "m=" section to a previously negotiated BUNDLE group,
>      the offerer follows the procedures in [Section 7.5].  The offerer

You should make clear that it's not possible to have an added m=
section that the peer can take as bundled or not.

S 8.1.
>      correct protocols.
>   
>   8.1.  STUN, DTLS, SRTP
>   
>      Section 5.1.2 of [RFC5764] describes a mechanism to identify the
>      protocol of a received packet among the STUN, DTLS and SRTP protocols

Nit "the correct"

S 9.2.
>         If the RTCP packet is a feedback request that includes target
>         SSRC(s), for each target SSRC that is found in the outgoing SSRC
>         table, deliver a copy of the RTCP packet to the "m=" section
>         associated with that SSRC.  PSFB and RTPFB types that are handled
>         in this way include:
>   

associates -> includes

S 9.3.1.2.
>      section, following the procedures for BUNDLE attributes
>      [Section 7.1.3].  In addition, if the "m=" section that is selected
>      as the offerer tagged "m=" section contained an SDP "rtcp-mux-only"
>      attribute, the answerer MUST include an SDP "rtcp-mux-only" attribute
>      in the answerer tagged "m=" section.
>   

You should rewrite this graf and the one below to be about BUNDLED-
ness not port assignment. I.e., if you are definitely bundled, willing
to bundle, or not bundled.

S 9.3.1.2.
>   
>      If the usage of RTP/RTCP multiplexing within a BUNDLE group has been
>      negotiated in a previous offer/answer exchange, the answerer MUST
>      include an SDP 'rtcp-mux' attribute in the answerer tagged "m="
>      section .  It is not possible to disable RTP/RTCP multiplexing within
>      a BUNDLE group.

Same point here as above. Talking about address:port isn't helpful.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 19 May 2018 13:32:31 -0700

Tools failure here failed to get my new review. Expect something correct
soon.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 19 May 2018 14:38:35 -0700

o  Initial offer: The first offer, within an SDP session (e.g. a SIP
      dialog when the Session Initiation Protocol (SIP) [RFC3261] is

It seems like you should define bundled "m=" section. I believe it's one
that appears in a bundle tag?

initial offer

MUST include

I'm having trouble reading this paragraph. How do you select an m= section
that correspond to the selected m= section.

criterion would be more standard English. criterium generally refers to a
bike race

   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.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 May 2018 07:50:42 +0000

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

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.

---

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

---

>      TRANSPORT multiplexing category SDP attributes (BUNDLE attributes)

Will fix.

---

>      attributes in all other bundled "m=" sections.  In the initial

Will fix.

---

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

---

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

---

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 21 May 2018 05:55:05 -0700

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

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

> This isn't a technical change. I just didn't see the definition.

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

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

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

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 May 2018 13:22:53 +0000

Hi,

...

> 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

What about:

   The answerer MUST select the "m=" section *in the answer* that corresponds to the
   selected offerer tagged "m=" section in the corresponding offer
   [Section 7.3.1] as the answerer tagged "m=" section.  In the answer
   the answerer BUNDLE-tag indicates the answerer tagged "m=" section.

...

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

I can do that.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Mon, 21 May 2018 10:15:32 -0500

On 5/21/18 7:55 AM, Eric Rescorla wrote:
>     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.
>
>

Ben is the responsible AD here, so I'm deferring to his judgement 
regarding whether the document can proceed.

Speaking only as a SIP protocol expert, I agree with EKR that the 
redefinition of a frequently used RFC-3264-defined term is problematic, 
and will probably lead to interoperability issues. When readers 
encounter a term that they believe they understand, it's unlikely that 
they will notice that it has been redefined to mean something different 
[1]. I believe that replacing the phrase with something distinctive -- 
such as "initial bundle offer" -- would alleviate this issue, with no 
real drawback. I would not think that such a change warrants sending the 
document back to the WG, but I won't argue against doing so if someone 
else thinks it does.

/a

____
[1] For the issue at hand, I'm reminded of Lewis Carrol's take on 
lexical semantics: 
http://www.literaturepage.com/read/throughthelookingglass-54.html

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 21 May 2018 08:27:58 -0700

>    the answerer BUNDLE-tag indicates the answerer tagged "m=" section.

This seems clearer, but I'm not sure what "selected" is doing in "selected
offerer tagged". Can you explain?

-Ekr

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 May 2018 15:30:49 +0000

Hi,

>>> 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.
>>
> Ben is the responsible AD here, so I'm deferring to his judgement regarding whether the document can proceed.
> Speaking only as a SIP protocol expert, I agree with EKR that the redefinition of a frequently used RFC-3264-defined 
> term is problematic, and will probably lead to interoperability issues. When readers encounter a term that they 
> believe they understand, it's unlikely that they will notice that it has been redefined to mean something different [1]. 
> I believe that replacing the phrase with something distinctive -- such as "initial bundle offer" -- would alleviate this issue, 
> with no real drawback. I would not think that such a change warrants sending the document back to the WG, but I won't 
> argue against doing so if someone else thinks it does.

I did previously suggest "initial bundle offer", but it did not address Ekr's issue.

It is also important to remember that this affects virtually every SDP attribute we define, unless there are cases where "initial offer" always means the initial offer of a session, i.e., it is not possible to introduce an attribute later in a session.

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Mon, 21 May 2018 10:33:18 -0500

> It is also important to remember that this affects virtually every SDP attribute we define, unless there are cases where "initial offer" always means the initial offer of a session, i.e., it is not…

I'm not following your logic here. Can you give an example?

/a

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 May 2018 15:37:35 +0000

Hi,

>> It is also important to remember that this affects virtually every SDP attribute we define, >> unless there are cases where "initial offer" always means the initial offer of a session, i.e., >> it is not possible to introduce an attribute later in a session.
>

Assume I establish a session, with audio and video.

The initial offer will contain the m- lines, and associated SDP attributes, for audio and video.

Later in the session, I send a subsequent offer, adding a BFCP m- line.

When setting the SDP attributes associated with the BFCP m- line, I will now use the "initial offer" procedures for those attributes, because it is the initial offer for those attributes (while a subsequent offer for the SIP session).

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 May 2018 16:23:10 +0000

...and, to use an example you may be more familiar with: RID.

Are you saying that the “initial offer” procedures can only be used for the initial offer of the SIP session, meaning I can’t introduce RID later in the session (to an existing and/or new m- line)? If so, I think that should be explicitly stated in the draft.

Regards,

Christer

Sent from my iPhone

On 21 May 2018, at 18.37, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 May 2018 16:34:13 +0000

In my opinion, if the problem is that there is a conflict with the terminology in RFC 3261 and/or 3264, then let’s fix those specs instead.

Regards,

Christer

Sent from my iPhone

On 21 May 2018, at 19.23, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Regards,

Christer

Sent from my iPhone

Hi,

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Mon, 21 May 2018 21:25:05 -0500

Sorry for jumping in late—I was on the road most of last week and am just catching up.

I think I share Adam’s view (and by extension, Ekr’s). More comments inline:

> On May 21, 2018, at 10:37 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

Sure.

(But be advised that if we are taking about rfc4583bis, that’s not the most convincing argument since it hasn’t been published yet, and RFC4583 does not use this structure at all.)

> Later in the session, I send a subsequent offer, adding a BFCP m- line.

Isn’t that a _modified_ offer? There’s a separate section for that.

> When setting the SDP attributes associated with the BFCP m- line, I will now use the "initial offer" procedures for those attributes, because it is the initial offer for those attributes (while a s…

This is where I (agreeing with Adam) think readers will get confused, because it’s out of sync with the SDP offer/answer. To extend your example, we end up with “initial SDP offer” == “no BFCP offer” and “modified (or subsequent) SDP offer” == “initial BFCP author”.

I see further down my mailbox list that you brought up RID. I will respond further there.

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 21 May 2018 21:51:20 -0500

> On May 21, 2018, at 11:23 AM, Christer Holmberg <[email-masked]> wrote:
> 
> ....and, to use an example you may be more familiar with: RID.
> 

*** MMUSIC Chairs and other SDP experts: Please feel free to jump in with your opinion about how we should expect the “Offer/answer considerations” sections be written in SDP extension RFCs. ***

I will let Adam confirm his intent, but I read the “initial SDP offer” section as talking about the initial _SDP_ offer”. It says the initial offer _MAY_ contain one or more “a=rid” lines. The "Modifying the Session” section then goes on to say that such an offer MAY change the number of RID lines in use. I argue that going from zero to one or more RID line counts as changing the number of RID lines in use.

I do not dispute that there may be some SDP extension RFCs that are written as you suggest. I would have to go back and re-read a bunch of documents to reasonably comment on how many. But picking a random target:

draft-ietf-mmusic-dtls-sdp-32 seems ambiguous on this point. The “Generating initial SDP offer” section is written from the assumption the initial offer includes DTLS-SRTP. But the “modifying a session” section talks about putting a new offer for DTLS-SRTP in a subsequent SDP offer. Taken as a whole, this seems more in the vein of “initial SDP offer” is really the initial SDP offer, and it just (reasonably) neglected to describe the case where the initial offer does not include DTLS-SRTP.

In the case of BUNDLE, I don’t think we are talking about a complete restructure. Just recognize the difference between invoking bundle in the initial SDP offer vs subsequent SDP offers. That probably means adding a few sentences to the “Initial SDP offer” and “Modifying the Session” sections.

Ben.

> Regards,
> 
> Christer
> 
> 
> Sent from my iPhone
> 
> On 21 May 2018, at 18.37, Christer Holmberg <[email-masked]> wrote:
> 
>> Hi,
>>

---

From: Ben Campbell <[email-masked]>
Date: Mon, 21 May 2018 21:55:10 -0500

> On May 21, 2018, at 11:34 AM, Christer Holmberg <[email-masked]> wrote:
> 

I don’t follow -- are you suggesting we should change the terminology in 3264 to match that of work-in-process extensions? Or did I misread that?

Ben.

> 
> Regards,
> 
> Christer
> 
> Sent from my iPhone
> 
> On 21 May 2018, at 19.23, Christer Holmberg <[email-masked]> wrote:
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 May 2018 03:14:49 +0000

Hi,

> I don’t follow -- are you suggesting we should change the terminology in 3264 to match that of work-in-process extensions? Or did I misread that?

I am saying that we have been using "initial offer" in SDP attribute extension specifications for many years, and I can't think of a single case where it would only apply to the initial offer of a session. It applies to the case where an SDP attribute is first added to an m- section (the m- section itself may not even be present in the initial offer of the session, but added later).

I can't think of a single case where we would have procedures that ONLY apply to the initial offer of a session. "Initial offer" always refer to the offer where the attribute is first added to an m- section.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 May 2018 03:20:54 +0000

Hi,

> I will let Adam confirm his intent, but I read the “initial SDP offer” section as talking about the initial _SDP_ offer”. It says the 
> initial offer _MAY_ contain one or more “a=rid” lines. The "Modifying the Session” section then goes on to say that such an 
> offer MAY change the number of RID lines in use. I argue that going from zero to one or more RID line counts as changing the number of RID lines in use.

The MAYs are not the issue. The "initial offer" section contains a list (7 bullets) of considerations when adding a rid attribute. The same list is not present in the "modifying session" section. Does that mean they only apply if one is adding a rid attribute in the initial offer of a session??? In my opinion they apply to whenever a new rid attribute is added - whether it's in the initial offer, or a subsequent offer, of a session.

>In the case of BUNDLE, I don’t think we are talking about a complete restructure. Just recognize the difference between invoking 
>bundle in the initial SDP offer vs subsequent SDP offers. That probably means adding a few sentences to the “Initial SDP offer” and 
>“Modifying the Session” sections.

What sentences?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 May 2018 06:35:22 +0000

Hi,

>draft-ietf-mmusic-dtls-sdp-32 seems ambiguous on this point. The “Generating initial SDP offer” section is written from the assumption 
>the initial offer includes DTLS-SRTP. But the “modifying a session” section talks about putting a new offer for DTLS-SRTP in a subsequent SDP offer. 
>Taken as a whole, this seems more in the vein of “initial SDP offer” is really the initial SDP offer, and it just (reasonably) neglected to describe the 
>case where the initial offer does not include DTLS-SRTP.

The "initial offer" applies when a DTLS association is to be established.

"Modifying the Session" applies when a DTLS association has previously been established.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 May 2018 06:47:33 +0000

Hi,

...

> This seems clearer, but I'm not sure what "selected" is doing in "selected offerer tagged". Can you explain?

The answerer first selects the offer tagged "m=" section, as described in section 7.3.1. After that, it selects the corresponding "m=" section in the answer as the answerer tagged "m=" section.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 May 2018 05:28:49 -0700

On Mon, May 21, 2018 at 11:47 PM, Christer Holmberg <
[email-masked]> wrote:

> > This seems clearer, but I'm not sure what "selected" is doing in
> "selected offerer tagged". Can you explain?
>
> The answerer first selects the offer tagged "m=" section, as described in
> section 7.3.1. After that, it selects the corresponding "m=" section in the
> answer as the answerer tagged "m=" section.
>

Well, the use of "selected" here in both cases is super-confusing.

I think what would be easiest would simply be to merge these two sections.
I.e., the answerer determines (it actually doesn't "select") the tagged m=
section and then places it in its own answer.

-Ekr

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 22 May 2018 10:14:30 -0400

In the past, we have had a lot of trouble getting people to write clear 
offer/answer procedures for the SDP extensions they defined. In an 
effort to put some structure around that, we started insisting on people 
following RFC 3264, which defines the following stages:

1. Generating the Initial Offer
2. Generating the Answer
3. Offerer Processing of the Answer
4. Modifying the Session

Clearly, any new SDP extensions MUST define how the extension is to be 
used with these well-defined RFC 3264 procedures.

Now, the argument here seems to be as to whether the "Modifying the 
Session" needs to get into a further level of granularity, e.g.
4a. Modifying the Session when the Extension was *not* used previously
4a1. Sending a Subsequent Offer with the Extension
4a2. Generating the Subsequent Answer to Subsequent Offer with the Extension
4a3. Offerer Processing of Subsequent Answer after Subsequent Offer with 
the Extension

If we need that, then we also need:
4b. Modifying the Session when the extension *was* used previously.
4b1. Sending a  Subsequent Offer without the Extension (assumed here to 
be different from 4 above, which would keep using the extension)
4b2. Generating the Subsequent Answer to Subsequent Offer without the 
Extension
4b3. Offerer Processing of Subsequent Answer after Subsequent Offer 
without the Extension.

We have shied away from requiring this structure in the documents 
because it becomes rather cumbersome, and in practice, it doesn't seem 
to be needed. Instead, the traditional RFC 3264 sections have generally 
been written in way that accommodates both the formal meaning of 
*initial* offer/answer exchange, as well as initial from the point of 
view of covering the first time the extension is used. In some cases, 
explicit caveats have been included to point this out (as has been done 
in bundle), and in others it has not. We have a number of published RFCs 
and IESG approved documents in MISSREF state that all follow this 
approach, and I cannot recall this resulting in any concerns from either 
the WG, the IESG, or implementers.

In summary, my position remains what it has been for a long time, which 
is to follow the RFC 3264 structure outlined above, with proper 
clarifications in each of the resulting sections to account for the 
variations outlined in 4a and 4b.

It's not clear to me that the current bundle document doesn't already 
achieve that, but if people feel otherwise, I would ask for specific 
text suggestions that could address that while keeping in-line with 
long-standing document structure MMUSIC has required for SDP extensions.

Thanks

-- Flemming (as WG co-chair and Individual)

---

From: Ben Campbell <[email-masked]>
Date: Tue, 22 May 2018 15:23:55 -0500

Adam and I (with AD hats on)  talked about this offline. Here’s our conclusions:

While I’m not overly happy about the conflation of the “initial SDP offer” section with “Initial activation of an extension” in general, I recognize we’ve been doing it that way. We might should discuss changing that for future drafts, but it’s not reasonable to force such a change on bundle this late in the process.

However, we think that implementors are too used to thinking of “initial offer” to mean “initial SDP offer” for a re-definition to stick in their minds. Especially not a one-time redefinition in a terminology section that many people will skip over. Therefore, we ask for the following changes:

1) Change the definition in the term section from “initial offer” to “initial bundle offer”. Do a human-assisted search and replace to change instances of “initial offer” to “initial bundle offer” where the change makes sense.

2) Add a sentence early in §7.2 to the effect of the following:

“The procedures in this section apply to the first SDP offer that contains a bundle group. This could occur in an initial SDP offer or a subsequent SDP offer.”

(I don’t think we need to add anything similar to §7.3 or §7.5. These sections already have language that, when taken with the proposed change to §7.2, seem to reasonably describe the intent”.

I don’t think these requires a restructure, nor should they take very long to accomplish.

Thoughts?

Thanks!

Ben.

> On May 22, 2018, at 9:14 AM, Flemming Andreasen <[email-masked]> wrote:
> 
> In the past, we have had a lot of trouble getting people to write clear offer/answer procedures for the SDP extensions they defined. In an effort to put some structure around that, we started insisting on people following RFC 3264, which defines the following stages:
> 
> Clearly, any new SDP extensions MUST define how the extension is to be used with these well-defined RFC 3264 procedures.
> 
> Now, the argument here seems to be as to whether the "Modifying the Session" needs to get into a further level of granularity, e.g.
> 4a3. Offerer Processing of Subsequent Answer after Subsequent Offer with the Extension
> 
> 4b1. Sending a  Subsequent Offer without the Extension (assumed here to be different from 4 above, which would keep using the extension)
> 4b2. Generating the Subsequent Answer to Subsequent Offer without the Extension
> 4b3. Offerer Processing of Subsequent Answer after Subsequent Offer without the Extension.
> 
> We have shied away from requiring this structure in the documents because it becomes rather cumbersome, and in practice, it doesn't seem to be needed. Instead, the traditional RFC 3264 sections have generally been written in way that accommodates both the formal meaning of *initial* offer/answer exchange, as well as initial from the point of view of covering the first time the extension is used. In some cases, explicit caveats have been included to point this out (as has been done in bundle), and in others it has not. We have a number of published RFCs and IESG approved documents in MISSREF state that all follow this approach, and I cannot recall this resulting in any concerns from either the WG, the IESG, or implementers.
> 
> In summary, my position remains what it has been for a long time, which is to follow the RFC 3264 structure outlined above, with proper clarifications in each of the resulting sections to account for the variations outlined in 4a and 4b.
> 
> It's not clear to me that the current bundle document doesn't already achieve that, but if people feel otherwise, I would ask for specific text suggestions that could address that while keeping in-line with long-standing document structure MMUSIC has required for SDP extensions.
> 
> Thanks
> 
>>> .....and, to use an example you may be more familiar with: RID.
>>> 
>>> On 21 May 2018, at 18.37, Christer Holmberg
>>> <[email-masked]>
>>>  wrote:
>>> 
>>> 
>>>> Hi,
>>>> 
>>>>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 May 2018 13:39:47 -0700

This is ultimately for the ADs to decide (hence, not a DISCUSS by me) but I
am fine with this.

-Ekr

On Tue, May 22, 2018 at 1:23 PM, Ben Campbell <[email-masked]> wrote:

> While I’m not overly happy about the conflation of the “initial SDP offer”
> section with “Initial activation of an extension” in general, I recognize
> we’ve been doing it that way. We might should discuss changing that for
> future drafts, but it’s not reasonable to force such a change on bundle
> this late in the process.
>
> However, we think that implementors are too used to thinking of “initial
> offer” to mean “initial SDP offer” for a re-definition to stick in their
> minds. Especially not a one-time redefinition in a terminology section that
> many people will skip over. Therefore, we ask for the following changes:
>
> 1) Change the definition in the term section from “initial offer” to
> “initial bundle offer”. Do a human-assisted search and replace to change
> instances of “initial offer” to “initial bundle offer” where the change
> makes sense.
>
> “The procedures in this section apply to the first SDP offer that contains
> a bundle group. This could occur in an initial SDP offer or a subsequent
> SDP offer.”
>
> (I don’t think we need to add anything similar to §7.3 or §7.5. These
> sections already have language that, when taken with the proposed change to
> §7.2, seem to reasonably describe the intent”.
>
> offer/answer procedures for the SDP extensions they defined. In an effort
> to put some structure around that, we started insisting on people following
> RFC 3264, which defines the following stages:
> >
> because it becomes rather cumbersome, and in practice, it doesn't seem to
> be needed. Instead, the traditional RFC 3264 sections have generally been
> written in way that accommodates both the formal meaning of *initial*
> offer/answer exchange, as well as initial from the point of view of
> covering the first time the extension is used. In some cases, explicit
> caveats have been included to point this out (as has been done in bundle),
> and in others it has not. We have a number of published RFCs and IESG
> approved documents in MISSREF state that all follow this approach, and I
> cannot recall this resulting in any concerns from either the WG, the IESG,
> or implementers.
> >
> achieve that, but if people feel otherwise, I would ask for specific text
> suggestions that could address that while keeping in-line with
> >>> On May 21, 2018, at 11:23 AM, Christer Holmberg <
> >>> Are you saying that the “initial offer” procedures can only be used
> for the initial offer of the SIP session, meaning I can’t introduce RID
> later in the session (to an existing and/or new m- line)? If so, I think
> that should be explicitly stated in the draft.
> >>>
> >>>
> >> *** MMUSIC Chairs and other SDP experts: Please feel free to jump in
> with your opinion about how we should expect the “Offer/answer
> considerations” sections be written in SDP extension RFCs. ***
> >>
> >> I will let Adam confirm his intent, but I read the “initial SDP offer”
> section as talking about the initial _SDP_ offer”. It says the initial
> offer _MAY_ contain one or more “a=rid” lines. The "Modifying the Session”
> section then goes on to say that such an offer MAY change the number of RID
> lines in use. I argue that going from zero to one or more RID line counts
> as changing the number of RID lines in use.
> >>
> >> I do not dispute that there may be some SDP extension RFCs that are
> written as you suggest. I would have to go back and re-read a bunch of
> documents to reasonably comment on how many. But picking a random target:
> >>
> >> draft-ietf-mmusic-dtls-sdp-32 seems ambiguous on this point. The
> “Generating initial SDP offer” section is written from the assumption the
> initial offer includes DTLS-SRTP. But the “modifying a session” section
> talks about putting a new offer for DTLS-SRTP in a subsequent SDP offer.
> Taken as a whole, this seems more in the vein of “initial SDP offer” is
> really the initial SDP offer, and it just (reasonably) neglected to
> describe the case where the initial offer does not include DTLS-SRTP.
> >>
> >> In the case of BUNDLE, I don’t think we are talking about a complete
> restructure. Just recognize the difference between invoking bundle in the
> initial SDP offer vs subsequent SDP offers. That probably means adding a
> few sentences to the “Initial SDP offer” and “Modifying the Session”
> sections.
> >>
> >>
> >> Ben.
> >>
> >>
> >>> Regards,
> >>>
> >>> Christer
> >>>
> >>>
> >>> Sent from my iPhone
> >>>
> >>>>>> It is also important to remember that this affects virtually every
> SDP attribute we define, >> unless there are cases where "initial offer"
> always means the initial offer of a session, i.e., >> it is not possible to
> introduce an attribute later in a session.
> >>>>>>
> >>>> When setting the SDP attributes associated with the BFCP m- line, I
> will now use the "initial offer" procedures for those attributes, because
> it is the initial offer for those attributes (while a subsequent offer for
> the SIP session).
> >>>>
> >>>> Regards,
> >>>>
> >>>> Christer
> >>>>
> >>>>
> >
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 22 May 2018 22:19:42 -0400

This seems like a very reasonable way forward to me.

Thanks

-- Flemming

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 May 2018 04:37:34 +0000

Hi,

I am happy with the suggested way forward, and will create a PR where I try to implement it.

Having said that, what do we do with other extensions that are still in the WGCL/IESG? For example, RTCWEB defines the SDP 'identity' attribute, and I have commented that the O/A procedures (together with some other clarifications) are needed for that. Another example is BFCPbis, where we are about to request publication for the 4583bis draft.

Regards,

Christer

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: 22 May 2018 22:24
To: Flemming Andreasen <[email-masked]>; Christer Holmberg <[email-masked]>; Adam Roach <[email-masked]>
Cc: [email-masked]; Eric Rescorla <[email-masked]>; mmusic WG <[email-masked]>; The IESG <[email-masked]>; [email-masked]
Subject: Re: Offer/Answer sections in SDP extension documents [Re: Eric Rescorla's No Objection on draft-ietf-mmusic-sdp-bundle-negotiation-51: (with COMMENT)]

Thoughts?

Thanks!

Ben.

> 4a1. Sending a Subsequent Offer with the Extension 4a2. Generating the 
> Subsequent Answer to Subsequent Offer with the Extension 4a3. Offerer 
> Processing of Subsequent Answer after Subsequent Offer with the 
> Extension
> 
> 4b1. Sending a  Subsequent Offer without the Extension (assumed here 
> to be different from 4 above, which would keep using the extension) 
> 4b2. Generating the Subsequent Answer to Subsequent Offer without the Extension 4b3. Offerer Processing of Subsequent Answer after Subsequent Offer without the Extension.
> 
>>> On May 21, 2018, at 11:23 AM, Christer Holmberg

---

From: Ben Campbell <[email-masked]>
Date: Tue, 22 May 2018 23:46:30 -0500

> On May 22, 2018, at 11:37 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 

Excellent, thanks!

> Having said that, what do we do with other extensions that are still in the WGCL/IESG? For example, RTCWEB defines the SDP 'identity' attribute, and I have commented that the O/A procedures (togeth…

I assume you are asking whether we will force them to follow my view of “initial SDP offer” vs “initial offer of the extension”. I’m not going to insist on restructuring mostly-done drafts as long as they are clear. And if they are not clear, I expect that someone will complain.  (I’m not picking on Ekr—that could easily be Adam, me, or someone else.)

I would like to see MMUSIC participants pick a long-term way forward, but I realize my view may not represent that consensus.

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 May 2018 06:20:23 +0000

Hi,

>> Having said that, what do we do with other extensions that are still in the WGCL/IESG? 
>> For example, RTCWEB defines the SDP 'identity' attribute, and I have commented that the 
>> O/A procedures (together with some other clarifications) are needed for that. Another example 
>> is BFCPbis, where we are about to request publication for the 4583bis draft.
>
> I assume you are asking whether we will force them to follow my view of “initial SDP offer” vs 
> “initial offer of the extension”. I’m not going to insist on restructuring mostly-done drafts as long 
> as they are clear. And if they are not clear, I expect that someone will complain.  (I’m not picking on 
> Ekr—that could easily be Adam, me, or someone else.)

My point is that, whatever wording we use, we have a common understanding of what it means.

For example, based on one of your previous comments, it seems (please correct me if I'm wrong) that you consider the "initial offer" section of RID to only apply to the initial offer of the session - not to the case where the RID extension is added in a subsequent offer. 

Even if we use "initial offer" or "initial RID offer", I think it would be good to add a similar clarification statement also to the RID draft.

> I would like to see MMUSIC participants pick a long-term way forward, but I realize my view may not represent that consensus.

Perhaps something we can discuss in Montreal?

Regards,

Christer

> To: Flemming Andreasen <[email-masked]>; Christer Holmberg 
> <[email-masked]>; Adam Roach <[email-masked]>
> Cc: [email-masked]; Eric Rescorla <[email-masked]>; mmusic WG 
> <[email-masked]>; The IESG <[email-masked]>; 
> [email-masked]
> Subject: Re: Offer/Answer sections in SDP extension documents [Re: 
> Eric Rescorla's No Objection on 
> draft-ietf-mmusic-sdp-bundle-negotiation-51: (with COMMENT)]
> 
>> 4a. Modifying the Session when the Extension was *not* used 
>> previously 4a1. Sending a Subsequent Offer with the Extension 4a2. 
>> Generating the Subsequent Answer to Subsequent Offer with the 
>> Extension 4a3. Offerer Processing of Subsequent Answer after 
>> Subsequent Offer with the Extension
>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 May 2018 07:32:43 +0000

Hi,

>> The answerer first selects the offer tagged "m=" section, as described in section 7.3.1. After that, it selects 
>> the corresponding "m=" section in the answer as the answerer tagged "m=" section.
>
> I think what would be easiest would simply be to merge these two sections. I.e., the answerer determines (it actually doesn't "select") 
> the tagged m= section and then places it in its own answer.

"Selected" is a terminology we spent quite a bit of time discussing back in the days, and it is used throughout the document. 

But, below is a suggestion on to merge the sections, which hopefully will be more clear:

7.3.1.  Answerer Selection of tagged 'm=' sections

   When the answerer selects the offerer tagged "m=" section, it first
   checks the suggested offerer tagged "m=" section [Section 7.2.1].
   The answerer MUST check whether the "m=" section fulfils the
   following criteria:

   o  The answerer will not move the "m=" section out of the BUNDLE
      group [Section 7.3.3]; and

   If all of the criteria above are fulfilled, the answerer MUST select
   the "m=" section as the offerer tagged "m=" section. In addition, in
   the corresponding answer, the answerer MUST select the "m=" section that
   corresponds to the offerer tagged "m=" section as the answerer 
   tagged "m=" section. In the answer the answerer BUNDLE-tag indicates the 
   answerer tagged "m=" section.

   If one or more of the criteria are not fulfilled, the answerer MUST
   pick the next identification-tag in the identification-tag list in
   the offer, and perform the same criteria check for the "m=" section
   indicated by that identification-tag.  If there are no more
   identification-tags in the identification-tag list, the answerer MUST
   NOT create the BUNDLE group.  Unless the answerer rejects the whole
   offer, the answerer MUST apply the answerer procedures for moving an
   "m=" section out of a BUNDLE group [Section 7.3.3] or rejecting an
   "m=" section within a BUNDLE group [Section 7.3.4] to every bundled
   "m=" section in the offer when creating the answer.

   [Section 17.1] shows an example of an offerer BUNDLE address:port
   selection.

   [Section 7.3.5] and [Section 17.1] show an example of an answerer
   tagged "m=" section selection.

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 May 2018 05:54:08 -0700

On Wed, May 23, 2018 at 12:32 AM, Christer Holmberg <
[email-masked]> wrote:

> > I think what would be easiest would simply be to merge these two
> sections. I.e., the answerer determines (it actually doesn't "select")
> "Selected" is a terminology we spent quite a bit of time discussing back
> in the days, and it is used throughout the document.
>

And yet it's extremely confusing the way it is used here.

>    answerer tagged "m=" section.

This is still confusing. There's no difference between these two
"selections".

   If all of the criteria above are fulfilled, the answerer MUST select
   the "m=" section as the offerer tagged "m=" section, and MUST also mark
    the corresponding m= section as the tagged "m=" section in its
   answer.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 May 2018 14:16:10 +0000

Hi,

...

> This is still confusing. There's no difference between these two "selections".
>

I modified to:

   "If all of the criteria above are fulfilled, the answerer MUST select
   the "m=" section as the offerer tagged "m=" section, and MUST also mark
   the corresponding "m=" section in the answer as the answerer tagged "m=" section.
   In the answer the answerer BUNDLE-tag indicates the answerer tagged "m=" section."

https://github.com/cdh4u/draft-sdp-bundle/pull/61/files

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 May 2018 09:11:14 -0700

Yes, OK

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 May 2018 17:25:22 +0000

Thanks!

Did you have a chance to look at the PR with the “initial offer” change?

Regards,

Christer

From: Eric Rescorla [mailto:[email-masked]]
Sent: 23 May 2018 18:11
To: Christer Holmberg <[email-masked]>
Cc: The IESG <[email-masked]>; Flemming Andreasen <[email-masked]>; [email-masked]; mmusic WG <[email-masked]>; [email-masked]
Subject: Re: Eric Rescorla's No Objection on draft-ietf-mmusic-sdp-bundle-negotiation-51: (with COMMENT)

Yes, OK

On Wed, May 23, 2018 at 7:16 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

...

I modified to:

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 23 May 2018 10:59:45 -0700

I have decided to trust Ben and Adam :)

-Ekr

On Wed, May 23, 2018 at 10:25 AM, Christer Holmberg <
[email-masked]> wrote:

> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* 23 May 2018 18:11
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* The IESG <[email-masked]>; Flemming Andreasen <[email-masked]>;
> [email-masked]; mmusic WG <[email-masked]>;
> *Subject:* Re: Eric Rescorla's No Objection on
> draft-ietf-mmusic-sdp-bundle-negotiation-51: (with COMMENT)
>
>
>
> Yes, OK
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 24 May 2018 06:18:23 +0000

Ok :)

Ben/Adam, can I merge the PR can submit a new version of the draft?

Regards,

Christer

On Wed, May 23, 2018 at 10:25 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Thanks!

Regards,

Christer

From: Eric Rescorla [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 23 May 2018 18:11
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>; Flemming Andreasen <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; mmusic WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Eric Rescorla's No Objection on draft-ietf-mmusic-sdp-bundle-negotiation-51: (with COMMENT)

Yes, OK

...

I modified to:

Regards,

Christer