[MMUSIC] [OFF LIST] Genart last call review of draft-ietf-mmusic-msrp-usage-data-channel-21

[Jose <[e-mail]>]

Hi, Christer,

Your experience really helps here, I would be a bit over my head on the 
topics related to mmusic ways.

I am assuming you will modify the draft and resubmit? Let me know if 
you'd rather me doing it.

JM

On 13/7/20 4:58 pm, Christer Holmberg wrote:
> Hi Brian,
>
> Thank You for the review! Please see inline.
>
>
> Nits:
> -----
>
>>> 4.1.  MSRP URI
>>> ....
>>>      transport  /= "dc"
>>>
>>> I see that RFC7977 takes a slightly different approach to updating the ABNF:
>>>
>>>      transport  =  "tcp" / "ws" / 1*ALPHANUM
>>>
>> The advantage of listing out
>>
>>   transport  =  "tcp" / "ws" / "dc" / 1*ALPHANUM
>>
>> would be that the reader sees the full list.
> The MMUSIC WG has previously decided to take the approach of only writing the new value, using the "/=" format.
>
> ---
>
>>>                   ; Add "dc" to existing transports per [RFC4975]
>>>
>>> I suggest
>>>
>>>                  ; Add "dc" to existing transports per Section 9 of [RFC4975]
> Will modify as suggested.
>
> ---
>
>>> 4.6.  Session Closing
>>>
>>>    The SDP answerer must ensure that no dcmap or dcsa attributes are
>>>    present in the SDP answer if no corresponding attributes are present
>>>    in the received SDP offer.
>>>
>>> Should that be MUST?
> The reason for "must" is that is referring to generic data channel SDP O/A procedures.
>
> I suggest to remove the paragraph.
>
> ---
>
>>> B2BUA
>>>
>>> Define the acronym please.
> We normally don't do that in MMUSIC specifications. Also, it is on the IETF list of well-known acronyms.
>
> Having said that, I am fine to enhance it on first occurrence: 'Back-to-Back User Agent (B2BUA)'
>
> ---
>
>>> 9.2.  Subprotocol Identifier MSRP
>>>
>>>    A reference to this document is added to the subprotocol identifier
>>>    "msrp" in the "WebSocket Subprotocol Name Registry"
>>>
>>> s/this document/RFCXXXX/
> Will modify as suggested.
>
> ---
>
>>> 11.  CHANGE LOG
>>>
>>> Mark this section for deletion by the RFC Editor
> I think the RFC Editor will delete it by default, but we can add explicit text.
>
> Regards,
>
> Christer