Skip to main content

Last Call Review of draft-ietf-mmusic-msid-13
review-ietf-mmusic-msid-13-opsdir-lc-hares-2016-06-13-00

Request Review of draft-ietf-mmusic-msid
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-06-14
Requested 2016-05-16
Authors Harald T. Alvestrand
Draft last updated 2016-06-13
Completed reviews Genart Last Call review of -13 by Matthew A. Miller (diff)
Secdir Last Call review of -13 by Rifaat Shekh-Yusef (diff)
Opsdir Last Call review of -13 by Susan Hares (diff)
Assignment Reviewer Susan Hares
State Completed
Review review-ietf-mmusic-msid-13-opsdir-lc-hares-2016-06-13
Reviewed revision 13 (document currently at 17)
Result Has Issues
Completed 2016-06-13
review-ietf-mmusic-msid-13-opsdir-lc-hares-2016-06-13-00

I have reviewed this document as part of the Operational directorate's

ongoing effort to review all IETF documents being processed by the IESG.  These

comments were written with the intent of improving the operational aspects of
the

IETF drafts. Comments that are not addressed in last call may be included in AD
reviews

during the IESG review.  Document editors and WG chairs should treat these
comments

just like any other last call comments.





Status:  Almost ready to go, 2 minor concerns, NIT



General comment:  Document and concept are generally clear.  Thank you for
providing a simple solution to this problem.



Caveat:  My expertise is at lower end of the stack.  I cross referenced all the
WebRTC documentation, but I’ve missed how implementations provide feedback that
this protocols is up and working.  Therefore, I’ve indicated the operational
issues as a set of questions for the authors to consider.



Minor concern:

1)



Error handling: Is it possible that the msid-value, msid-id, and msid-appdata
can be inserted, and then received with values that are not valid 
(1*64token-char]?

a.



 If so, an error sequence is necessary.

b.



If not, it is important to explain why not

Add section to 3.2

2)



Operational  issues:  A few questions for your to consider to provide the link
to operational issues.



Normal operational:  How does the person who is utilizing this protocol in
WebRTC situation check the status of the protocols?  Is it part of the WebRTC
status information that the implementations provide?  If so, is there any
common management parameters that you can suggest?  Is this in another document
in IETF or W3C?



Error operations:  If you can have errors, how does the person who utilizes
this protocol in WebRTC  find out the error rate.  Again, is it part of the
WebRTC status information on errors?  Is it in another document W3C?





Editorial NITS:

Page 7, section 3.1



Paragraph 2:  double “,” in the section highlighted makes this sentence’s
meaning unclear.

Are these two sub-thoughts? If not two sub-thoughts, then perhaps the /new/
suggested text.



   When MSID is used,

the only time this can happen is when, at a time

   subsequent to the initial negotiation,

a negotiation is performed

   where the answerer adds a MediaStreamTrack

 t

o 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.



/new suggested/

When MSID is used,

the only time this can happen is at a time

   subsequent to the initial negotiation,

/



Paragraph 3



Pagination makes the following text difficult.  Repagination in /new/ may
help.  Or it may highlight where I was confused by your document.



/old/

The recipient of those packets will perform the following steps:



   o  When RTP packets are initially received, it will create an

      appropriate MediaStreamTrack based on the type of the media

      (carried in PayloadType), and use the MID RTP header extension

      [

I-D.ietf-mmusic-sdp-bundle-negotiation

] (if present) to associate

      the RTP packets with a specific media section.  If the connection

      is not in the RTCSignalingState "stable", it will wait at this

      point.



   o  When the connection is in the RTCSignalingState "stable", it will

      look at the relevant media section to find the msid attribute.



   o  If there is an msid attribute, it will use that attribute to

      populate the "id" field of the MediaStreamTrack and associated

      MediaStreams, as described above.



   o  If there is no msid attribute, the identifier of the

      MediaStreamTrack will be set to a randomly generated string, and

      it will be signalled as being part of a MediaStream with the

      WebIDL "label" attribute set to "Non-WebRTC stream".



   o  After deciding on the "id" field to be applied to the

      MediaStreamTrack, the track will be signalled to the user.

/



/new/

The recipient of those packets will perform the following steps:



   o  When RTP packets are initially received, it will create an

      appropriate MediaStreamTrack based on the type of the media

      (carried in PayloadType), and use the MID RTP header extension

      [

I-D.ietf-mmusic-sdp-bundle-negotiation

] (if present) to associate

      the RTP packets with a specific media section.

-



If the connection is not in the RTCSignalingState "stable", it will wait at
this point.

-



When the connection is in the RTCSignalingState "stable", it will look at the
relevant media section to find the msid attribute.



·



Looking a Media section:

o



If there is an msid attribute, it will use that attribute to populate the "id"
field of the MediaStreamTrack and associated MediaStreams, as described above.

o



If there is no msid attribute, the identifier of the MediaStreamTrack will be
set to a randomly generated string, and it will be signalled as being part of a
MediaStream with the  WebIDL "label" attribute set to "Non-WebRTC stream".



   o  After deciding on the "id" field to be applied to the

      MediaStreamTrack, the track will be signalled to the user.

/