Re: [MMUSIC] Stephen Farrell's Discuss on draft-ietf-mmusic-msid-14: (with DISCUSS)

[Alissa Cooper <[e-mail]>]

> On Jun 16, 2016, at 4:39 AM, Stephen Farrell <[e-mail]> wrote:
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-mmusic-msid-14: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> 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 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.

Alissa

> 
> 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?
> 
> 
> 
>