Brian, thanks for your review. Christer, thanks for addressing Brian’s comments. I entered a No Objection ballot. Alissa > On Jul 13, 2020, at 4:51 PM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > > 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 >> > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
