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

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Apr 2018 19:22:49 +0000

Hi,

In this reply I address the COMMENTs.

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

>>    Negotiating Media Multiplexing Using the Session Description Protocol
>>                                    (SDP)
>>               draft-ietf-mmusic-sdp-bundle-negotiation-49.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.

This is discussed in the thread following Adam's comments.

---

>> to negotiate which "m=" sections will become part of a BUNDLE group.
>> Within a BUNDLE group, each "m=" section will use a BUNDLE
>> transport for sending and receiving bundled media.
>>   
>> Within a BUNDLE group, each endpoint uses a single address:port
>> combination for sending and receiving bundled media.  The
> 
> Nit: "pair"?

"combination" has been used in the draft for a long time, and is also used
in other places.

Anyway, I guess this may go away depending on the outcome of the "address:port" discussion.

---

>> combination for sending and receiving bundled media.  The
>> address:port combination is referred to as the BUNDLE address:port.
>> In addition to negotiating the BUNDLE group, the offerer and answerer
>> [RFC3264] use the BUNDLE extension to negotiate the BUNDLE
>> addresses:ports, one for the offerer (offerer BUNDLE address) and
>> one for the answerer (answerer BUNDLE address:port).  Once the offerer
>
> Why is one of these called "address" and the other "address:port"?

Both shall be "address:port". 

Again, I guess this may also go away depending on the outcome of the "address:port" discussion.

---

>> can be used to request that specific media is only used if the "m="
>> section describing the media is kept within a BUNDLE group.
>>   
>> This specification updates RFC 3264 [RFC3264], to allow assigning a
>> zero port value to a "m=" section without meaning that the media
>> described by the "m=" section is disabled or rejected.
> 
> 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.
>
>> can be used to request that specific media is only used if the "m="
>> section describing the media is kept within a BUNDLE group.
>>   
>> This specification updates RFC 3264 [RFC3264], to allow assigning a
>> zero port value to a "m=" section without meaning that the media
>> described by the "m=" section is disabled or rejected.
> 
> This section is kind of a laundry list. I think it would be helpful to
> break it out conceptually. Specifically.
> 1.
> 2.
> 3.

I will take a look.

---

>> "m=" section: SDP bodies contain one or more media descriptions,
>> referred to as "m=" sections.  Each "m=" section is represented by
>> an SDP "m=" line, and zero or more SDP attributes associated with the
>> "m=" line.  A local address:port combination is assigned to each
>> "m=" section.
>
> Was this intended to be a bullet?

Yes. Will be fixed.

---

>> 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 dialog when the Session Initiation Protocol (SIP) [RFC3261] is
>>     used to carry SDP), in which the offerer indicates that it wants
>>     to create a given 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.

I believe there are other drafts with similar definitions of "Initial
Offer".

Anyway, would something like "Initial BUNDLE offer" be better?

---

>> The BUNDLE extension is indicated using an SDP 'group' attribute
>> with 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.
> 
> How about "is part of" instead of "associated with"

There are most likely other instances that would have to be fixed, and I'd like to try to maintain consistent terminology. 

---

>>      Each "m=" section whose identification-tag is listed in the
>>      identification-tag list is associated with a given BUNDLE group.
>>   
>>      SDP bodies can contain multiple BUNDLE groups.  Any given bundled
>>      "m=" section MUST NOT be associated with more than one BUNDLE group
>>      at any given time.
> 
> Again "part of"

There are multiple instances of "associated with BUNDLE group" terminology throughout the document.

---

>> assign a zero port value to the "m=" section.  According to
>> [RFC3264] an answerer will reject such an "m=" section.  By including an SDP
>> 'bundle-only' attribute in such an "m=" section, the offerer can
>> request that the answerer accepts the "m=" section if the answerer
>> supports the BUNDLE extension, and if the answerer keeps the "m="
>> section within the associated BUNDLE group.
> 
> I would put some of this text up before the attribute definition to
> explain why the attribute exists.

I suggest moving up the whole paragraph.

---

>> SDP offers and answers can contain multiple BUNDLE groups.  The
>> procedures in this section apply independently to a given BUNDLE
>> group.
>>   
>> 8.1.  Multiplex Category Considerations
> 
> Multiplexing?

It used to be "Mux Category Considerations", but someone requested to modify to "Multiplex".

But, I am ok with "Multiplexing", as that is also used in draft-ietf-mmusic-sdp-mux-attributes, so I will fix as suggested.

---

>> When a BUNDLE group is initially negotiated, and a unique
>> address:port is assigned to each bundled "m=" section (excluding
>> any bundle-only "m=" section) in the initial offer [Section 8.2], any
>> IDENTICAL and TRANSPORT mux category SDP attributes included in the
>> BUNDLE group MUST explicitly be included in each bundled
>>  "m=a&#128;&#156; section (excluding any bundle-only "m=" sections).
> 
> Something bad happened here with your editor.

Will be fixed.

---

>> BUNDLE group MUST explicitly be included in each bundled
>> "m=a&#128;&#156; section (excluding any bundle-only "m=" sections).
>>   
>> When an offerer or answerer includes SDP attributes in bundled "m="
>> sections within a BUNDLE group for which the offerer and answerer
>> BUNDLE addresses:ports have been selected, IDENTICAL and TRANSPORT
> 
> 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).

I suggest to remove "for which the offerer and answerer BUNDLE addresses:ports have been selected".

---

>> The semantics of some SDP attributes only apply to specific types of
>> media.  For example, the semantics of the SDP 'rtcp-mux' and SDP
>> 'rtcp-mux-only' attributes only apply to "m=" sections describing
>> RTP-based media.  However, as described in Section 8.1, there are
>> cases where IDENTICAL and TRANSPORT mux category SDP attributes are
>> only included in the "m=" sections indicated by the BUNDLE-tag.
>> That
> 
> Huh? This is section 8.1.

It should be "as described above".

> 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"
> type of media.

I will take a look.

---

>> 8.2.  Generating the Initial SDP Offer
>>   
>>     When an offerer generates an initial offer, to negotiate a BUNDLE
>>     group, it MUST:
> 
> This sentence is ungrammatical. "In order to negotiate a BUNDLE group
> in an initial offer, the offerer MUST"

In an earlier version of the draft the text said:

"When an offerer generates an initial offer, in order to create a BUNDLE
group, it MUST:"

I was then asked to remove the "in order to".

But, I can modify as suggested, because I do agree that it sounds better.

---

>> within the BUNDLE group, the offerer MUST:
>>   
>> o  Include an SDP 'bundle-only' attribute [Section 8.2.1] in the
>>     "m=" section; and
>>   
>> o  Assign a zero port value to the "m=" section.
> 
> I would reorder these, because the zero port is the main semantic.

I will modify as suggested.

---

>> NOTE: If the offerer assigns unique addresses:ports to multiple
>> bundled "m=" sections, the offerer needs to be prepared to receive
>> bundled media on each unique address:port, until it receives the
>> associated answer and finds out which address:port combination has
>> been selected as the offerer BUNDLE-address.
> 
> 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

I suggest to move up the paragraph, and replace "If" with "When".

---

>> It is RECOMMENDED that the offerer assigns the suggested offerer
>> BUNDLE address:port to a bundled "m=" section that the offerer
>> assumes it is unlikely that the answerer will reject, or move out
>> of the BUNDLE group.  How such assumption is made is outside the scope
>> of this document.
>
> I would say "believes" rather than "assumes"

I will modify as suggested.

---

>> b=AS:1000
>> a=mid:bar
>> a=rtcp-mux
>> a=rtpmap:31 H261/90000
>> a=rtpmap:32 MPV/90000
>> a=extmap 1 urn:ietf:params:rtp-hdrext:sees:mid
>
> Line breaks between the m= sections would help here.

I will modify as suggested.

---

>> When an answerer generates an answer that contains a BUNDLE group,
>> the following general SDP grouping framework restrictions, defined
>> in [RFC5888], also apply to the BUNDLE group:
>>   
>> o  The answerer MUST NOT include a BUNDLE group in the answer,
>>     unless
>
> Comma not needed here.

Will fix.

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

That would result in:

      o  The answerer MUST only include a BUNDLE group in the answer if
        the offerer requested the BUNDLE group to be negotiated in the
        corresponding offer; and

      o  The answerer MUST only include an "m=" section within a BUNDLE
        Group if the offerer requested the "m=" section to be within
        that BUNDLE group in the corresponding offer.

I think that is weird. If I do the change, I guess "MUST" should be
replaced with e.g., "can":

      o The answerer can only include a BUNDLE group in the answer if
        the offerer requested the BUNDLE group to be negotiated in the
        corresponding offer; and

      o The answerer can only include an "m=" section within a BUNDLE
        Group if the offerer requested the "m=" section to be within
        that BUNDLE group in the corresponding offer.

---

>> o  The answerer MUST NOT include an "m=" section within a BUNDLE
>>     group, unless the offerer requested the "m=" section to be within
>>     that BUNDLE group in the corresponding offer.
>>   
>> o  If the answer contains multiple BUNDLE groups, the answerer MUST
>>     NOT move an "m=" section from one BUNDLE group to another.
>
> This bullet is unnecessary as it immediately follows from the
> proceeding bullet.

I will remove the second bullet.

---

>> If the answer contains a BUNDLE group, the answerer MUST:
>>   
>> o  Select an offerer BUNDLE address:port [Section 8.3.1]; and
>>   
>> o  Select an answerer BUNDLE address:port [Section 8.3.2].
>
> This isn't right, because each BUNDLE group has its own address:port,
> so instead "For each BUNDLE group" contained in the offer.

The procedures is for individual BUNDLE groups, as indicated in Section 8:

 "SDP offers and answers can contain multiple BUNDLE groups.  The
  procedures in this section apply independently to a given BUNDLE
  group."

> 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

I don't understand what "first m= section which will be BUNDLEd" means. What is "first"?

---

>> o  The answerer will not reject the "m=" section [Section 8.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 suggested offerer BUNDLE address:port.
>
> Again, this isn't selecting the address:port but rather the m=section

Sure, but it picks the address:port of that selected m= section.

---

>> bundled "m=" section the answerer MUST assign a zero port value and
>> include an SDP 'bundle-only' attribute.
>>
>> The answerer MUST NOT assign an answerer BUNDLE address:port to an
>> "m=" section that is not within the BUNDLE group, or to an "m="
>> section that is within another BUNDLE group.
>
> This repeats text in S 8.3.

What text do you think is repeated?

---

>> group in an answer, it MUST first check the following criteria:
>>
>> o  In the corresponding offer, an offerer BUNDLE address:port
>>     (previously selected [Section 8.3.1] or newly suggested
>>     [Section 8.5.1]) has been assigned to the "m=" section by the
>>     offerer; or
>
> 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.

Actually, based on the current procedures, if the BUNDLE group exists,
either criteria will always be fulfilled, so the only way for the answerer
to move a bundled m- line out of a group is by sending an offer, as
described later in the section.

Also, the text contains "includes a BUNDLE group" terminology, but also
covers cases where the BUNDLE group has not yet been created. So, I think
the procedures for the answerer needs to be split into:

1. Creating initial answer, where the offerer asks for a BUNDLE group to
be negotiated
2. Creating answer to subsequent answer, where a BUNDLE group has
previously been negotiated.

I will try to come up with something.

---

>> either reject the whole offer, reject each bundled "m=" section
>> within the BUNDLE group [Section 8.3.4], or keep the "m=" section
>> within the BUNDLE group in the answer and later create an offer
>> where the "m=" section is moved out of the BUNDLE group [Section 8.5.3].
>>
>> When the answerer generates an answer, in which it moves a bundled
>
> No comma

Will fix.

---

>> o  MUST NOT assign an SDP 'bundle-only' attribute to the "m="
>>      section.
>>
>> An answerer MUST NOT move an "m=" section from one BUNDLE group to
>> another within an answer.  If the answerer wants to move an "m="
>
> This is the third time you have said this. If you want to say it here,
> say "Because ..., if"

I will modify as suggested.

---

>> it MUST first check the following criteria:
>>
>> o  In the corresponding offer, an offerer BUNDLE address:port
>>     (previously selected [Section 8.3.1] or newly suggested
>>     [Section 8.5.1]) has been assigned to the "m=" section by the
>>     offerer.
>
> Same comment here as above. These are entirely different conditions.

See above.

---

>> o  In the corresponding offer, an offerer BUNDLE address:port
>>     (previously selected [Section 8.3.1] or newly suggested
>>     [Section 8.5.1]) has been assigned to the "m=" section by the
>>     offerer.
>>
> If the criteria above is fulfilled, the answerer can not reject the
> 
> "criteria... are"

Someone said it should be "is", but I am fine using "are", and can fix as suggested.

---

>> reject the whole offer, reject each bundled "m=" section within the
>> BUNDLE group, or keep the "m=" section within the BUNDLE group in
>> the answer and later create an offer where the "m=" section is disabled
>> within the BUNDLE group [Section 8.5.4].
>>   
>> When an answerer generates an answer, in which it rejects a bundled
> 
> No comma

Will fix.

---

>> m=video 0 RTP/AVP 32
>> b=AS:1000
>> a=mid:bar
>> a=bundle-only
>> a=rtpmap:32 MPV/90000
>> a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
> 
> Please put line breaks in between m= sections here too

Will do.

---

>>   8.4.  Offerer Processing of the SDP Answer
>>   
>>      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,
>
> address:port, again. It's the m=section that's relevant.

Yes, but it uses the address:port of the m= section.

What do you suggest to say instead?

---

>> bundled "m=" section.
>>   
>> NOTE: As the answerer might reject one or more bundled "m=" sections,
>> or move a bundled "m=" section out of a BUNDLE group, each bundled
>> "m=" section in the offer might not be indicated as bundled in the
>> answer.
> 
> "each" -> "an given"

I will change as suggested (I assume you mean "a given").

---

>> When the offerer generates a subsequent offer, the offerer
>> BUNDLE-tag MUST represent the bundled "m=" section to which the offerer BUNDLE
>> address:port (previously negotiated or newly suggested) has been assigned.
>>   
>> 8.5.1.  Suggesting a New Offerer BUNDLE Address:Port
> 
> Again it would make more sense to describe this as suggesting a new m= section.

It does not have to be a new "m=" section. The new address:port can be assigned to an existing "m=" section.

---

>> section out of a BUNDLE group.
>>   
>> 8.5.4.  Disabling a Media Description in a BUNDLE Group
>>   
>> When an offerer generates an offer, in which it wants to disable a
>> bundled "m=" section, the offerer:
> 
> Are you sure disable -> port 0, as opposed to "inactive"

Yes. "disable" terminology is also used in RFC 3264.

---

>> configuration and packetization.
>> [I-D.ietf-mmusic-sdp-mux-attributes] lists SDP attributes, whose
>> attribute values are required to be identical for all codecs that
>> use the same payload type value.
>>   
>>   10.2.  Associating RTP/RTCP Streams with Correct SDP Media Description
> 
> Nit "the correct"

Will fix.

---

>> "m=" sections), following the procedures for IDENTICAL mux category
>> attributes in Section 8.1.  In addition, the offerer MAY include an
>> SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] in a
>> RTP-based bundled "m=" section.
>>   
>> NOTE: Whether the offerer associates the SDP 'rtcp-mux-only¹
>
> associates -> includes

Will fix.

---

>> an offerer BUNDLE address:port (previously selected
>> [Section 8.3.1] or newly suggested [Section 8.5.1]) to a bundled
>> "m=" section (the "m=" section indicated by the offerer BUNDLE-
>> tag), the offerer only includes ICE-related media-level SDP
>> attributes in that "m=" section, following the procedures in
>> Section 8.1.
>
> 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.

Will look into it.

---

>> Support and usage of ICE mechanism together with the BUNDLE
>> extension is OPTIONAL, and the procedures in this section only apply when the
>> ICE mechanism is used.  Note that applications might mandate usage
>> of the ICE mechanism even if the BUNDLE extension is not used.
>>   
>>   11.1.  SDP Offer/Answer Procedures
> 
> Same point here as above. Talking about address:port isn't helpful.

Will look into it.

---

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Apr 2018 13:13:45 -0700

> In this reply I address the COMMENTs.

OK.

> "combination" has been used in the draft for a long time, and is also used

I'm prepared to believe both of these statements, but in my experience
"pair" is far more common.

> I believe there are other drafts with similar definitions of "Initial

Perhaps, but as I noted, 3264s disagrees.

> Anyway, would something like "Initial BUNDLE offer" be better?

Not really.

> There are most likely other instances that would have to be fixed, and I'd
> like to try to maintain consistent terminology.
>

Yes, I would change all of them.

> There are multiple instances of "associated with BUNDLE group" terminology

Yes, and they're all bad.

> I suggest moving up the whole paragraph.

OK.

> addresses:ports have been selected".

O

> I suggest to move up the paragraph, and replace "If" with "When".

OK.

>         that BUNDLE group in the corresponding offer.

OK.

>   group."'

I don't find this very clear.

> I don't understand what "first m= section which will be BUNDLEd" means.

The one indicated by the bundle tag.

> Sure, but it picks the address:port of that selected m= section.

No, it picks the m= section and then uses the attached address:port.

> What text do you think is repeated?

8.3. already says you can't move between BUNDLE groups.

> I will try to come up with something.

OK.

> Someone said it should be "is", but I am fine using "are", and can fix as

OK, well, "criteria" is the plural of "criterion"

> What do you suggest to say instead?

"MUST use the indicated m= section as the bundle <whatever term we choose>"

> assigned to an existing "m=" section.

You're suggesting that a new m= section be the one that things are bundled
into.

> Yes. "disable" terminology is also used in RFC 3264.

All right.

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Apr 2018 09:28:46 +0000

Hi,

> "pair" is far more common.

Ok. So, if we end up using "address:port" I will change "combination" to "pair".

---

>> I believe there are other drafts with similar definitions of "Initial Offer".
>>

So, what do you suggest?

Note that, for most SDP extensions I can think of, "initial offer" refers to the offer where you actually start using the extension (explicitly or implicitly). 

---

> Yes, I would change all of them.

I have a quick look, and I am not sure we can change all instances of "associated with" to "is part of".

---

> Yes, and they're all bad.

Why?

---
 
> I don't find this very clear.

I am not sure adding "For each BUNDLE group" all over (it would be needed in more places than indicated above) would make it better.

So, my preference would be to work on the clarification text above, if you think it needs to be more clear.

---

> The one indicated by the bundle tag.

In my ears "First" seems to reference the order of the "m=" section in the SDP, but the bundle tag can indicate any of the "m=" sections.

---

> No, it picks the m= section and then uses the attached address:port.

I don't disagree.

---

> 8.3. already says you can't move between BUNDLE groups.

Ok, but I don't think that covers the fact that you can't assign the address:port to an m= section that isn't part of a BUNDLE group.

---

> OK, well, "criteria" is the plural of "criterion"

Ok.

---

> "MUST use the indicated m= section as the bundle <whatever term we choose>"

"bundle m- section" would be a straight forward choice. However, that is very similar to "bundled m- section", which refers to any m- section within a BUNDLE group...

---

> You're suggesting that a new m= section be the one that things are bundled into.

Not necessarily. The new address:port is assigned to *a* bundled m= section, which could be the *same* m= section currently used to bundle things into.

---

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Apr 2018 05:49:48 -0700

On Wed, Apr 18, 2018 at 2:28 AM, Christer Holmberg <
[email-masked]> wrote:

> Note that, for most SDP extensions I can think of, "initial offer" refers
> to the offer where you actually start using the extension (explicitly or
> implicitly).
>

But that's not the case here, because this is the one for this BUNDLE
group, not for BUNDLE as a whole

I'm not sure you need a specific term here. How often do you use it?

---
> >>> There are most likely other instances that would have to be fixed, and
> I'd like to try to maintain consistent terminology.
> >>

Yes, quite possibly, but that's an argument against using "associated" in
this way. Find a set of more specific terms and use them.

> > Yes, and they're all bad.

Because it's a generic term when specific ones would be bette

> I am not sure adding "For each BUNDLE group" all over (it would be needed
> in more places than indicated above) would make it better.
>

I'm not sure how to fix this. Perhaps it needs a real rewrite

> In my ears "First" seems to reference the order of the "m=" section in the
> SDP, but the bundle tag can indicate any of the "m=" sections.
>

Sure. I'm not suggesting text in this specific case, I'm trying to provide
a structure that explains what's going on

> > No, it picks the m= section and then uses the attached address:port.

Right, but the document throughout (see my other email about trickle) acts
like its the address that is the key

> Ok, but I don't think that covers the fact that you can't assign the
> address:port to an m= section that isn't part of a BUNDLE group.
>

Sure, so state the rules in one place

> "bundle m- section" would be a straight forward choice. However, that is
> very similar to "bundled m- section", which refers to any m- section within
> a BUNDLE group...
>

When Adam and I were talking yesterday he suggested "lead" m= section.

> Not necessarily. The new address:port is assigned to *a* bundled m=
> section, which could be the *same* m= section currently used to bundle
> things into.
>

Sure, but again, it's not the address:port that's being suggested, it's its
parameters

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Apr 2018 14:30:42 +0000

Hi,

>> But that's not the case here, because this is the one for this BUNDLE group, not for BUNDLE as a whole
>>

It’s based on the generic structure that MMUSIC has defined for the O/A procedures of new attributes:

  *   Generating initial offer
  *   Generating answer
  *   Modifying the session

Sure, we could use a structure like:

  *   Creating BUNDLE group
     *   Generating offer
     *   Generating answer
  *   Modifying BUNDLE group
     *   Generating offer
        *   Add/remove m- section etc
     *   Generating answer
        *   Add/remove m- section etc

…where the focus would be on whether a bundle group is created or modified, without caring about whether it’s the initial offer of the session or not.

But, we would not be using the generic O/A structure.

---

> Yes, quite possibly, but that's an argument against using "associated" in this way. Find a set of more specific terms and use them.
> Because it's a generic term when specific ones would be better

How do I know in which cases to use something more “specific”?

For example:

 "media associated with the BUNDLE group": Is media part of the group? Or, is there some other more specific word to use?

 "identification-tag list is associated with a given BUNDLE group": Is the list part of the group? Or, is there some other more specific word to use?

 "The c= line net type value associated with  the bundled m= section”: Is the c= line part of the m= section? I don’t think so – at least not in case of a session-level c= line.

Etc…

---

> I'm not sure how to fix this. Perhaps it needs a real rewrite

What needs a rewrite?

---

> Sure. I'm not suggesting text in this specific case, I'm trying to provide a structure that explains what's going on

Ok.

---

> Right, but the document throughout (see my other email about trickle) acts like its the address that is the key

Even though trickle is a special case, I get your point. I assume the usage of address:port is because that is what triggered the work in the first place. Later we added the procedures regarding other parts (SDP attributes etc).

---

>>>>> "m=" section that is not within the BUNDLE group, or to an "m=“

I will look into it.

---

Ok.

---

> Sure, but again, it's not the address:port that's being suggested, it's its parameters

Well, in this particular case, the text is about changing the address:port.

But, even if we change that and talk about parameters, it still doesn’t have to be a new m= section. You can modify the parameters of the existing bundle/lead/whatever m= section.

---

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Apr 2018 08:05:15 -0700

On Wed, Apr 18, 2018 at 7:30 AM, Christer Holmberg <
[email-masked]> wrote:

> >> Note that, for most SDP extensions I can think of, "initial offer"
> refers to the offer where you actually start using the extension
> (explicitly or implicitly).
> >>
>    - Generating initial offer
>    - Generating answer
>    - Modifying the session
>
>    - Creating BUNDLE group
>       - Generating offer
>       - Generating answer
>    - Modifying BUNDLE group
>       - Generating offer
>          - Add/remove m- section etc
>       - Generating answer
>          - Add/remove m- section etc
>
>
> …where the focus would be on whether a bundle group is created or
> modified, without caring about whether it’s the initial offer of the
> session or not.
>

I'm not seeing a problem with that

> >>>>> There are most likely other instances that would have to be fixed,
> and I'd like to try to maintain consistent terminology.
> >>>>
> > Yes, quite possibly, but that's an argument against using "associated"
> in this way. Find a set of more specific terms and use them.

Almost every case

> For example:
>
>  "media associated with the BUNDLE group": Is media part of the group?
> Or, is there some other more specific word to use?
>

"m=" section that is part of a bundle group

 "identification-tag list is associated with a given
BUNDLE group": Is the list part of the group? Or, is there some other more
specific word to use?

"identification-tag list for a given bundle group"

 "The c= line net type value associated with  the bundled m= section”: Is
the c= line part of the m= section? I don’t think so – at least not in case
of a session-level c= line.

"the c=line net type value that applies to the bundled m= section"

>> I am not sure adding "For each BUNDLE group" all over (it would be
needed in more places than indicated above) would make it better.

What needs a rewrite?

The section we are discussing

But, even if we change that and talk about parameters, it still doesn’t
have to be a new m= section. You can modify the parameters of the existing
bundle/lead/whatever m= section.

Yes, I agree with that

-Ekr

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Apr 2018 18:29:14 +0000

Hi,

>> • Generating initial offer
>> • Generating answer
>> • Modifying the session
>> 
>> • Creating BUNDLE group 
>>    o Generating offer
>>    o Generating answer
>> • Modifying BUNDLE group 
>>    o Generating offer 
>>         • Add/remove m- section etc
>>    o Generating answer 
>>         • Add/remove m- section etc
>>
>> …where the focus would be on whether a bundle group is created or modified, without caring about 
>> whether it’s the initial offer of the session or not.
>>

I think some do, e.g., the chairs.

I have personally also been strict about it when reviewing documents written by others, but I have no problem allowing other structures if seen more appropriate - if everyone is ok with it.

---

> "m=" section that is part of a bundle group

Yes, but I am talking about the media. Is media part of the group?

>> BUNDLE group": Is the list part of the group? Or, is there some other more specific word to use?
>

How is "for" more specific than "associated"?

>> "The c= line net type value associated with  the bundled m= section”: Is the c= line part of the m= section? 
>> I don’t think so – at least not in case of a session-level c= line.
>

How is "applies" more specific than "associated"?

I get that you don't like the use of the word "associated". But, in general, coming up with a bunch of different words just to get rid of "associated" doesn't make sense to me. It's a pure editorial choice, and every author has his/her favourite preference, and I think having consistent terminology is more important than finding the best word.

Having said that, if there is a case where a different word would really make things more clear, I am happy to look at it.

(Also note that I did get rid of a number of "associated" instances during the changes done based on WGLC reviews etc.)

Regards,

Christer

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Apr 2018 12:22:07 -0700

> Yes, but I am talking about the media. Is media part of the group?

I would have to see the text in context.

> >> "The c= line net type value associated with  the bundled m=
> section”: Is the c= line part of the m= section?

The answer to both of these is the same. You are using the word associated
for a number of different things, and so having different terms is clearer.

> I get that you don't like the use of the word "associated". But, in
> general, coming up with a bunch of different words just to get rid of
> "associated" doesn't make sense to me. It's a pure editorial choice, and
> every author has his/her favourite preference, and I think having
> consistent terminology is more important than finding the best word.
>

It's not a pure editorial choice. It's a source of confusion to have an
overloaded term.

-Ekr

Having said that, if there is a case where a different word would really
> make things more clear, I am happy to look at it.
>
> (Also note that I did get rid of a number of "associated" instances during
> the changes done based on WGLC reviews etc.)
>
> Regards,
>
> Christer
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Apr 2018 06:49:36 +0000

Hi,

> I would have to see the text in context.

E.g., section 1 contains the following sentence:

 “The endpoints then use the BUNDLE addresses:ports for sending and
  receiving the bundled media associated with the BUNDLE group."

Regards,

Christer

---

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

On Apr 18, 2018, at 9:22 PM, Eric Rescorla <[email-masked]> wrote:

> The answer to both of these is the same. You are using the word associated for a number of different things, and so having different terms is clearer.
> 
>> 
> It's not a pure editorial choice. It's a source of confusion to have an overloaded term.

I think it is an editorial choice. Furthermore, I think it’s a question of style, in which the authors have a fair amount of latitude. Does anyone think that the choice is going to cause implementors to make material errors?

Ben.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Apr 2018 06:27:05 -0700

On Wed, Apr 18, 2018 at 11:49 PM, Christer Holmberg <
[email-masked]> wrote:

> This actually seems like a time that "associated" would be fine.

-Ekr

Regards,

---

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

> I have personally also been strict about it when reviewing documents written by others, but I have no problem allowing other structures if seen more appropriate - if everyone is ok with it.

Agreed. We have been using this structure and consistently asked authors 
to use it as well for a long time. It's an established MMUSIC practice 
in dealing with offer/answer procedures and I'm not in favor of changing 
this.

Thanks

-- Flemming (with both my individual and chair hat on).

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 22 Apr 2018 10:41:51 -0400

On 4/19/18 5:28 AM, Ben Campbell wrote:
>
>
> On Apr 18, 2018, at 9:22 PM, Eric Rescorla <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> The answer to both of these is the same. You are using the word 
>> associated for a number of different things, and so having different 
>> terms is clearer.
>>
>>
>>     I get that you don't like the use of the word "associated". But,
>>     in general, coming up with a bunch of different words just to get
>>     rid of "associated" doesn't make sense to me. It's a pure
>>     editorial choice, and every author has his/her favourite
>>     preference, and I think having consistent terminology is more
>>     important than finding the best word.
>>
>>
> I think it is an editorial choice. Furthermore, I think it’s a 
> question of style, in which the authors have a fair amount of 
> latitude. Does anyone think that the choice is going to cause 
> implementors to make material errors?
>
I don't. I will also note that the document has undergone numerous 
revisions with significant terminology rewrite on multiple occasions to 
try and satisfy diverse comments from a significant number of people. 
The terminology that is found in the document represents a compromise 
that the WG participants have consensus on.

Thanks

-- Flemming (with chair and individual hat on)

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 22 Apr 2018 16:12:55 -0400

On 4/22/18 10:36 AM, Flemming Andreasen wrote:

>> I have personally also been strict about it when reviewing documents 
>> written by others, but I have no problem allowing other structures if 
>> seen more appropriate - if everyone is ok with it.
> 

This has also bothered me a bit. The structure was adopted for SDP O/A 
in the context of a dialog. And in that context the structure is well 
defined, where the first O/A really requires some different 
consideration than subsequent O/A.

*This* usage is different, in the the first offer of a bundle might not 
be the first offer of SDP in the dialog. It is potentially confusing to 
mix these two. Reusing the *structure* makes sense, but doing something 
to make clear that this is not the same is a good idea.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 22 Apr 2018 21:40:50 +0000

Hi,

>> Agreed. We have been using this structure and consistently asked 
>> authors to use it as well for a long time. It's an established MMUSIC 
>> practice in dealing with offer/answer procedures and I'm not in favor 
>> of changing this.
>
> This has also bothered me a bit. The structure was adopted for SDP O/A in the context of a dialog. 
> And in that context the structure is well defined, where the first O/A really requires some different consideration than subsequent O/A.
>
> *This* usage is different, in the the first offer of a bundle might not be the first offer of SDP in the dialog. 
> It is potentially confusing to mix these two. Reusing the *structure* makes sense, but doing something to 
> make clear that this is not the same is a good idea.

There IS text in the draft clarifying that:

      "Initial offer: The first offer, within an SDP session (e.g. a SIP
      dialog when the Session Initiation Protocol (SIP) [RFC3261] is
      used to carry SDP), in which the offerer indicates that it wants
      to create a given BUNDLE group."

This is not even BUNDLE specific - I think there are very few (I can't think of any straight from my head) SDP extension where you would be required to do something in the initial offer of the dialog.

Regards,

Christer

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 24 Apr 2018 10:29:39 -0400

> This is not even BUNDLE specific - I think there are very few (I can't think of any straight from my head) SDP extension where you would be required to do something in the initial offer of the dial…
Agreed.

-- Flemming
> Regards,
>
> Christer
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>