WebRTC MediaStream Identification in the Session Description Protocol
draft-ietf-mmusic-msid-17
Yes
(Spencer Dawkins)
No Objection
(Alexey Melnikov)
(Alia Atlas)
(Alvaro Retana)
(Deborah Brungard)
(Jari Arkko)
(Kathleen Moriarty)
(Mirja Kühlewind)
(Suresh Krishnan)
(Terry Manderson)
Note: This ballot was opened for revision 14 and is now closed.
Alissa Cooper Former IESG member
Yes
Yes
(2016-06-14 for -14)
Unknown
= Section 2 = OLD Multiple media descriptions with the same value for msid-id and msid- appdata is not permitted. NEW Multiple media descriptions with the same combination of msid-id and msid- appdata are not permitted. = Section 3 = s/and when the corresponding media description is disabled/or when the corresponding media description is disabled/
Ben Campbell Former IESG member
Yes
Yes
(2016-06-10 for -14)
Unknown
I made some editorial comments in my AD evaluation[1] that have not yet been addressed due to an email misconnect. There are no showstoppers there, so I'd like to move this along in parallel. [1] https://mailarchive.ietf.org/arch/msg/mmusic/KejxusGmZxF6IcEyKmlftpQqosw
Spencer Dawkins Former IESG member
Yes
Yes
(for -14)
Unknown
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -14)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -14)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -14)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(2016-06-14 for -14)
Unknown
No sure the following is useful information: This document is a work item of the MMUSIC WG, whose discussion list is mmusic@ietf.org. First time I see this in an abstract.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -14)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -14)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2016-06-14 for -14)
Unknown
Susan Hares <shares@ndzh.com> performed the opsdir review. Copied here for completeness as it hasn't been addressed yet. --- 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 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. /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. / _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -14)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -14)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2016-06-24 for -14)
Unknown
My old discuss text was: START I'm not sure that the answer to this question will require any change to the document but wanted to check... I wondered about the privacy properties of these (and related) WebRTC identifiers, esp. if they are being handled at various different layers. Is there work somewhere in the WebRTC space that's analysing that? For example, one concern might be that msid-appdata could end up with some kind of privacy sensitive value, but there's no guidance here about that and as the examples use UUIDs it's not clear to me those represent nor what typical values will be used. (Note: I'm not saying that I believe this is a problem, I'm just checking if it's been considered.) I hope that there's no reason why these can't be very ephemeral values that don't identify (or help re-identification of) people or their preferences, locations etc., and I'd imagine there's little reason to e.g. log them. If that's the case wouldn't it be useful to add such guidance (somewhere, maybe not here) to help developers to do the right thing? END Alissa suggested: I wonder if adding a reference to https://www.w3.org/TR/mediacapture-streams/#dom-mediastream-id <https://www.w3.org/TR/mediacapture-streams/#dom-mediastream-id> or parroting that guidance would help. And in response to a mail from Harald I then said: Given that the W3C document has the details, I've cleared the discuss. I do think it'd be good to at least have a reference to that as Alissa suggested and perhaps to also re-iterate a bit of the advice about avoiding fingerprinting perhaps.
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -14)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -14)
Unknown