Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-usage-data-channel-07 - Bo's editorial comments

[Bo Burman <[e-mail]>]

Thanks, LGTM

> -----Original Message-----
> From: Christer Holmberg
> <christer.holmberg=[e-mail]>
> Sent: den 5 november 2019 15:00
> To: Bo Burman <[e-mail]>; mmusic ([e-mail])
> <[e-mail]>
> Cc: '[e-mail]' <[e-mail]>
> Subject: Re: [MMUSIC] Starting shepherd's review of draft-ietf-mmusic-t140-
> usage-data-channel-07 - Bo's editorial comments
>
> Hi,
>
> In this reply I address Bo’s editorial comments and nits.
>
> >a) In section 1, note 2, suggest to change:
> >Old: “…over a data channel, instead of using RTP based transport [RFC4103],
> in WebRTC is constituted by use-case…”
> >New: “…over a data channel in WebRTC, instead of using RTP based
> transport [RFC4103], is motivated by use-case…”
>
> I suggest:
>
> "...using a WebRTC data channel, instead of using RTP based transport
> [RFC4103], is motivated by use-case..."
>
> ---
>
> >b) Section 4.2.3: “negotite" -> “negotiate”
>
> Will fix.
>
> ---
>
> >c) Section 4.2.3.1; Is this extra level heading needed? It’s not a strong
> opinion but the resulting 5 levels is a bit deep and section 4.2.3 is already
> “Real-time Text Direction”, so it should be clear >that having “Generating an
> Offer” etc. sub-headings apply to SDP negotiation.
>
> I will remove the "Negotiate Text Direction" level heading.
>
> ---
>
> >d) In section 4.2.3.1.1, “neither send or” -> “neither send nor”
>
> Will fix.
>
> ---
>
> >e) In section 4.2.3.1.1, “a ‘inactive’” -> “an ‘inactive’”
>
> Will fix.
>
> ---
>
> >f) In section 4.2.3.1.1, in the part to move (above), suggest to change “…not
> support the procedures in…” to “…not support the text direction procedures
> in…”.
>
> Will modify as suggested.
>
> ---
>
> >g) In section 4.2.3.1.1, the last part of the section describes when the
> offerer receives an answer to the offer and doesn’t fit under “Generating an
> Offer”; suggest moving that text to a separate >clause ‘4.2.3.1.3 Offerer
> Receiving an Answer’.
>
> I will modify as suggested.
>
> ---
>
> >h) In section 4.3, suggest changing ‘The maximum character transmission
> >rate is set to 20, and the default text transmission direction "sendrecv",
> apply’ to ‘The maximum character transmission rate is set to 20 and the
> default text transmission direction "sendrecv" applies’.
>
> Will modify as suggested.
>
> ---
>
> >i) In section 5.4, in the note, remove duplicate ‘the’.
>
> Will fix.
>
> ---
>
> >j) In section 5.5, in the note, “are able present” -> “are able to present”.
>
> Will fix.
>
> ---
>
> >k) In section 6, suggest changing “packet switched” -> “packet-switched”
> and “circuit switched” -> “circuit-switched”
>
> Will fix.
>
> ---
>
> >l) In section 6, suggest consider removing “etc” after “obsoleted”, or
> elaborate more.
>
> I will remove "etc".
>
> ---
>
> >m) In section 6, the last note, suggest changing “…a mechanism to provide
> such end-to-end encryption has not been defined” to “…no mechanism to
> provide such end-to-end encryption is >defined”.
>
> Will modify as suggested.
>
> ---
>
> >n) In section 7, “retreive" -> “retrieve”.
>
> Will fix.
>
> ---
>
> >Datatracker also finds the following
> https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/dra
> ft-ietf-mmusic-t140-usage-data-channel-07.txt:
> >• The “Updates: “ line should list only the numbers of the updated RFCs;
> change “RFC8373” to “8373”.
>
> Will fix.
>
> >• In section 4.2.1, a reference is made to “[Section 6]”, which is a document-
> internal reference and should remove the “[ ]”.
>
> I will change it to "(Section 6)".
>
> ---
>
> I have created a pull request for the changes, and the first commit contains
> the changes based on the editorial comments above:
>
> https://protect2.fireeye.com/v1/url?k=476c0bff-1be6c13c-476c4b64-
> 86e1ed4002b1-3aacfb0a5eb9371a&q=1&e=e06757da-955c-4e4d-957f-
> 9a8b9bb24acf&u=https%3A%2F%2Fgithub.com%2Fcdh4u%2Fdraft-
> datachannel-t140%2Fpull%2F52
>
> Regards,
>
> Christer
>