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

["Matt Miller (mamille2)" <[e-mail]>]

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.