Will do. Thanks!
Regards,
Christer
From: Murray S. Kucherawy <superuser@xxxxxxxxx>
Sent: torstai 16. heinäkuuta 2020 18.51
To: Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>
Cc: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>; gen-art@xxxxxxxx; draft-ietf-mmusic-msrp-usage-data-channel.all@xxxxxxxx; last-call@xxxxxxxx; mmusic@xxxxxxxx
Subject: Re: [Gen-art] Genart last call review of draft-ietf-mmusic-msrp-usage-data-channel-21
If you email the files to
internet-drafts@xxxxxxxx and Cc: me, I'll approve them and then the secretariat will put the update in the tracker.
-MSK
Hi,
I have created a new version (-22) of the draft, based on Brian's comment.
Murray, as the submission window is currently closed, are you able to manually submit the new version if I send you the files?
Regards,
Christer
-----Original Message-----
From: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>
Sent: maanantai 13. heinäkuuta 2020 23.52
To: Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>;
gen-art@xxxxxxxx
Cc:
draft-ietf-mmusic-msrp-usage-data-channel.all@xxxxxxxx;
last-call@xxxxxxxx; mmusic@xxxxxxxx
Subject: Re: [Gen-art] Genart last call review of draft-ietf-mmusic-msrp-usage-data-channel-21
Thanks Christer, that all looks good to me,
Regards
Brian
On 13-Jul-20 20:58, 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
>
|
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
