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

[Benjamin Kaduk <[e-mail]>]

On Sat, Apr 14, 2018 at 03:06:34PM +0000, Christer Holmberg wrote:
> Hi Benjamin,
> 
> Thank You for the review! Please see inline.
> 
> ----------------------------------------------------------------------
> 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.
> 
> 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]."
>       
> ---

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

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

OK

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

OK, I'll look for another reply.

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

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.

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

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

SGTM.

Thanks!

-Benjamin