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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 23 Aug 2021 15:57:44 -0700

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.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Aug 2021 17:16:48 +0000

Hi Benjamin,

Thanks for your review and comments!

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

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

---

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

 > 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

> 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

> 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

> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 31 Aug 2021 13:40:08 -0700

Hi Christer,

> Thanks for your review and comments!

They will have to pester the AD about it, but it's good to have them
helping the AD to remember to do it.

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

Seems reasonable.

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

Sounds good.

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

I agree that "offerer-tagged "m=" section" is defined to only apply to
subsequent offers, but I still think it's worth saying "offer (subsequent)"
-- there's not much context in this sentence to remind the reader that
"offerer-tagged "m=" section" is a defined term.

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

Right, the answerer is not allowed to move across groups ... but we've seen
buggy or broken implementations before, and it's probably wise for offerers
to not blindly assume that the answerer is correctly implemented.  The
answere should still validate the correctness of the input it receives.

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

Sure.

>    rejects the "m=" section (Section 7.3.3) the answerer MUST NOT include

That seems to make sense; thanks!
This does allow the answere to accept the "m=" section in the BUNDLE group,
which may or may not have been allowed by the old text.  I assume you will
know if that's okay.

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

Hooray :)

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

Fair enough :)

Thanks for the updates,

Ben