Re: [Gen-art] Review of draft-ietf-mmusic-msid-13

[Jari Arkko <[e-mail]>]

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) <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art