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

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mmusic-rfc8843bis-04: 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 DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc8843bis/



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

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.

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.

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.

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.

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

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.

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.