Subject: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-sdp-bundle-negotiation-49: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 13 Apr 2018 13:46:21 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mmusic-sdp-bundle-negotiation-49: 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:
----------------------------------------------------------------------

Should the NOTE in Section 8.5.2 explicitly reaffirm that only one
m= section within the BUNDLE group can have the offerer BUNDLE
address:port, regardless of whether it is a new or preexisting
address:port?  That is, that you cannot use an existing BUNDLE
address:port and offer a new one in the same BUNDLE group.

When we talk about how the offerer must move a section out of one
BUNDLE group and then generate a second offer where that section is
added to the other BUNDLE group (this occurs in several places,
IIRC), do we need to say anything about the offer that moves the
section out of the first BUNDLE group must be accepted before the
second offer is offered?

In Section 10.2, page 23, I appreciate the description of the
payload type/m= mapping used by legacy implementations, but I worry
that there may not be sufficient description of when an SDP participant
should take the care to ensure the uniqueness of the mapping (versus
when the legacy considerations can be ignored).

Does the first paragraph of Section 10.3.1.2 imply that an
implementation of BUNDLE must also implement rtcp-mux-only?

Should the RTP SDES header extension URI be mentioned somewhere
other than the IANA considerations?

In Section 17:
   The security considerations of "RTP Header Extension for the RTP
   Control Protocol (RTCP) Source Description Items" [RFC7941] requires
   that when RTCP is confidentiality protected, and that any SDES RTP
   header extension carrying an SDES item, such as the MID RTP header
   extension, is also protected using commensurate strength algorithms.
"that when [...], and that" seems the wrong construction here; I
think that just "that when [...]," is the intended meaning.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 14 Apr 2018 15:06:34 +0000

Hi Benjamin,

Thank You for the review! Please see inline.

> Should the NOTE in Section 8.5.2 explicitly reaffirm that only one m= section within the BUNDLE group 
> can have the offerer BUNDLE address:port, regardless of whether it is a new or preexisting address:port?  
> That is, that you cannot use an existing BUNDLE address:port and offer a new one in the same BUNDLE group.

I can add a sentence to the end of the Note:

   "NOTE: If the offerer also wants to suggest a new offerer BUNDLE
   address:port to the BUNDLE group, the offerer can assign the newly
   suggested offerer BUNDLE address:port either to the added "m="
   section, or to some other "m=" section within the BUNDLE group
   [Section 8.5.1]. To every other "m=" section within the BUNDLE group
   the offerer will assign a zero port value and an SDP 'bundle-only' attribute
   [Section 8.5.1]."
      
---

> When we talk about how the offerer must move a section out of one BUNDLE group and then generate a second offer
> where that section is added to the other BUNDLE group (this occurs in several places, IIRC), do we need to say anything
> about the offer that moves the section out of the first BUNDLE group must be accepted before the second offer is offered?

It is a basic 3264 rule that whatever changes are done in an offer only become valid once they have been accepted by the answerer.

---

> In Section 10.2, page 23, I appreciate the description of the payload type/m= mapping used by legacy
> implementations, but I worry that there may not be sufficient description of when an SDP participant should 
> take the care to ensure the uniqueness of the mapping (versus when the legacy considerations can be ignored).

Section 10 was "outsourced", so I will ask the folks who provided the text to reply :)

Magnus, Colin?

----

> Does the first paragraph of Section 10.3.1.2 imply that an implementation of BUNDLE must also implement rtcp-mux-only?

Yes. I could add a sentence to the following paragraph in section 10.2.:

   "Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP
   multiplexing [RFC5761] for the RTP-based media specified by the
   BUNDLE group. In addition, the offerer and answerer MUST support the
   SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive]."

----

> Should the RTP SDES header extension URI be mentioned somewhere other than the IANA considerations?

It is mentioned in Section 10.1:

      "o  The RTP MID header extension MUST be enabled, by including an SDP
      'extmap' attribute [RFC8285], with a 'urn:ietf:params:rtp-
      hdrext:sdes:mid' URI value, in each bundled RTP-based "m=" section
      in every offer and answer."

---

> "that when [...], and that" seems the wrong construction here; I think that just "that when [...]," is the intended meaning.

Correct. I suggest:

   "The security considerations of "RTP Header Extension for the RTP
   Control Protocol (RTCP) Source Description Items" [RFC7941] requires
   that when RTCP is confidentiality protected, then any SDES RTP
   header extension carrying an SDES item,..."

---

Regards,

Christer

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 16 Apr 2018 11:13:11 -0500

> Thank You for the review! Please see inline.

That seems consistent with the rest of the document and addresses my
question, thanks.

> It is a basic 3264 rule that whatever changes are done in an offer only become valid once they have been accepted by the answerer.

OK

> Section 10 was "outsourced", so I will ask the folks who provided the text to reply :)

OK, I'll look for another reply.

>    SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive]."

That will probably make things more clear (not that I expect many
folks to actually be confused by it), in the goal of making
depnedencies explicit.

>       in every offer and answer."

That must have gone by too quickly while I was searching for the
keyword through the document, sorry for missing it.  Do we want to
say that it's a new thing, at this mention?

>    header extension carrying an SDES item,..."

SGTM.

Thanks!

-Benjamin

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 16 Apr 2018 18:13:56 +0000

Hi,

> That must have gone by too quickly while I was searching for the keyword through the document, sorry for missing it.  
> Do we want to say that it's a new thing, at this mention?

Something like:

"with the 'urn:ietf:params:rtp-hdrext:sdes:mid' URI value defined in this specification"

Regards,

Christer

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 16 Apr 2018 13:21:23 -0500

> Hi,

Yeah, something like that.  Maybe "as defined" or "(defined in this
specification)", but I'm sure you can come up with something
reasonable.

Thanks,

Benjamin

---

From: Colin Perkins <[email-masked]>
Date: Wed, 25 Apr 2018 12:35:44 +0100

[Apologies for the slow response]

> On 14 Apr 2018, at 16:06, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Benjamin,
> 
…
>> In Section 10.2, page 23, I appreciate the description of the payload type/m= mapping used by legacy implementations, but I worry that there may not be sufficient description of when an SDP participant should take the care to ensure the uniqueness of the mapping (versus when the legacy considerations can be ignored).
> 

The legacy considerations can be ignored when both participants understand and use the identification-tag carried in the RTP and RTCP packets. If the identification-tag is not used, or not understood, then the comments about associating RTP flows with “m=“ sections based on payload type values apply.

-- 
Colin Perkins
https://csperkins.org/