Thanks! Were these comments noted by the authors? Or possibly even addressed in -14?
Jari On 25 May 2016, at 03:29, Matt Miller (mamille2) <[email protected]> wrote: > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for > the IETF Chair. Please treat these comments just like any other last call > comments. > > For more information, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Document: draft-ietf-mmusic-msid-13 > Reviewer: Matthew A. Miller > Review Date: 2016-05-24 > IETF LC End Date: 2016-05-24 > IESG Telechat date: N/A > > Summary: > > This document is ready for publication as a Proposed Standard once > some minor editorial nits are address. > > Major issues: NONE > > Minor issues: NONE > > Nits/editorial comments: > > * idnits is complaining that something smells of code that isn't bounded. > However, I think it is clear that the "suspicious text" is the detailed > SDP example, and is already clearly noted as such. > > * idnits warns of a number of outdated references, which I assume will > be updated with the next revision of this document or by the RFC Editor: > > - draft-ietf-mmusic-sdp-mux-attributes-02 > - draft-ietf-rtcweb-jsep-07 > - draft-ietf-mmusic-sdp-bundle-negotiation-07 > - draft-ietf-rtcweb-overview-10 > > * In Section 1.1. "Structure Of This Document", there is a spacing issue > in "WebRTC[I-D.ietf-rtcweb-overview] ." > > * In Section 2. "The Msid Mechanism", there is an extra "." in > "... defined in [W3C.WD-webrtc-20150210]., and to ...". > > * In Section 3.1. "Handling of non-signalled tracks", some of the > phrasing in the third paragraph seems awkward to me. Might I suggest > the following instead: > > When MSID is used, the only time this can happen is when, after the > initial negotiation, a negotiation is performed where the answerer > adds a MediaStreamTrack to an already established connection and > starts sending data before the answer is received by the offerer. > For initial negotiation, packets won't flow until the ICE candidates > and fingerprints have been exchanged, so this is not an issue. > > * Also in Section 3.1. "Handling of non-signalled tracks", I think the > sentence after the bullet list ought to be split in two between "entered" > and "If": > > The process above may involve a considerable amount of buffering > before the stable state is entered. If the implementation wishes to > limit this buffering, it MUST signal to the user that media has been > discarded. > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
