Re: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-rfc8843bis-04: (with COMMENT)

[Christer Holmberg <[e-mail]>]

Hi Benjamin,

Thanks for your review and comments!

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

>The errata report eid 6437 should probably be marked as "Verified" (or at least something other than "Reported") since it is being fixed in this update.

Yes. I have informed the chairs about that, but I will remind them.

>Since I reviewed draft-ietf-mmusic-sdp-bundle-negotiation before it became RFC 8843, I don't have much left to say about this document.  I did look over the diffs between the version I reviewed, RFC 8843 itself, and this version; 
>there was one point (mentioning the URI allocation for the RTP SDES header extension in the main body of the document) that got some proposed text in email but didn't seem to make it into this
>document:
>https://mailarchive.ietf.org/arch/msg/mmusic/eFxsB6G-_LmrEDMSOxfc16tzVhU/ .
>It's a quite minor point, so not a problem if the change is not made.

Nobody objected to adding the text, so if you want I can do it.

---

Some other remarks from looking over the document as a whole:

Section 7.2.2

>Perhaps s/The example/The following example/ (twice), since there are two examples in this section.

I will fix as suggested.

---

Section 7.3.1

 >  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.2) or rejecting an
 >  "m=" section within a BUNDLE group (Section 7.3.3) to every bundled
 >  "m=" section in the offer when creating the answer.
 >
 > Just to confirm: the last sentence only applies in the "no more identification-tags" case described by the preceding sentence?  I wonder if it's worth adding a couple words to solidify that connection.

Perhaps saying: "In addition, unless the answerer rejects,...."

---

Section 7.3.3

>   When an answerer wants to reject a bundled "m=" section in an answer,
>   it MUST first check the following criterion:
>
>   *  In the corresponding offer, the "m=" section is the offerer-tagged
>      "m=" section.
>
> The definition of "offerer-tagged "m=" section" is doing some heavy lifting here, by requiring that it be in a *subsequent* offer.  I wonder if this is worth calling out here, since 
> the defined term also has a natural reading as a generic phrase, which would give a different meaning.

Since the  offerer-tagged "m=" section only applies to subsequent offers, I think it is implicit.

However, if you think it is unclear, perhaps we could say "offer (subsequent)"

---

Section 7.4

>   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.  [...]
>
> By my reading, this doesn't require the offerer to check that the "m="
> sections in the answer are still in the same BUNDLE group that they were in in the offer (if there are multiple BUNDLE groups active).

Section 7.3 says that an answerer is only allowed to include a bundled "m=" section in the same BUNDLE groups as the bundled "m=" line in the corresponding offer.

But, perhaps we could say: "was indicated as bundled in the corresponding offer (for the same BUNDLE group)"

---

Section 9.3.1.2

>   In an initial BUNDLE offer, if the suggested offerer-tagged "m="
>   section contained an SDP 'rtcp-mux-only' attribute, the "m=" section
>   was for RTP-based media; thus, the answerer does not accept the "m="
>   section in the created BUNDLE group, and the answerer MUST move the
>   "m=" section out of the BUNDLE group (Section 7.3.2); include the
>   attribute in the moved "m=" section and enable RTP/RTCP multiplexing
>   for the media associated with the "m=" section; or reject the "m="
>   section (Section 7.3.3).
>
> I'm having a hard time parsing this (long!) sentence.  The first semicolon seems to be used to join related sentences, but the latter two seem to be acting as list
> separators (where the list members have internal commas), and that's a little jarring to have the different semicolon uses in the same sentence.  Additionally, if
> I keep that parsing, this seems to say that all "m=" sessions for RTP-based media cannot be included in the BUNDLE group by the answerer, which is quite surprising.
> If we applied s/thus,/thus, if/ and s/, and/,/, then this parsing would make more sense to me, but I don't know if that would provide the intended semantics.

What about:

   "In an initial BUNDLE offer, if the suggested offerer-tagged "m="
   section contained an SDP 'rtcp-mux-only' attribute, the "m=" section
   was for RTP-based media. If the answerer does not accept the "m="
   section in the created BUNDLE group, and moves the
   "m=" section out of the BUNDLE group (Section 7.3.2), the answerer
   MUST include the attribute in the moved "m=" section and enable RTP/RTCP
   multiplexing for the media associated with the "m=" section. If the answerer
   rejects the "m=" section (Section 7.3.3) the answerer MUST NOT include
   the attribute."

---

Section 16

>Did we consider reframing the IANA considerations along the lines of "update the existing registration to use this document as a reference"?
>Doing that makes it a little easier to understand the history of the registry entries, though needing the history is admittedly a rather uncommon case.

Yes, we did, and the intention is to fix that in the next version of the document :)

---

Section 17

>It seems that the logic for routing bundled RTP/RTCP messages to the proper media stream processor could be quite complex, and complex systems are potentially prone to error, but I'm not really sure there's a useful way to acknowledge that in the security considerations here.

I don't think it belongs to the Security Considerations.

Also, people may have different opinions on what is complex to implement :)

----

Regards,

Christer