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

[Christer Holmberg <[e-mail]>]

Hi Benjamin,

I will not reply to your input on Lars' comments, as there are no further issues.

----------------------------------------------------------------------
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.
>
> They will have to pester the AD about it, but it's good to have them helping the AD to remember to do it.

Ok.

Flemming/Bo, please handle this.

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

Wil be added.

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

Will be fixed.

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

I will change to "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.
>
> 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.

Will be fixed.

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

I think the old text also allowed that, but I agree that the lack of "and" before "the answerer does not accept" might make that unclear.

Or, did you refer to something else?

---
 
>> 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 :)
>
> Hooray :)

:)

---
 
>> 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 :)
>
> Fair enough :)
>
> Thanks for the updates,

Thanks!

Regards,

Christer