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

[Stephen Farrell <[e-mail]>]

On 16/06/16 15:20, Alissa Cooper wrote:
> 
>> 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.
> 

That'd certainly be good enough to clear the discuss. I'd still
be interested in an answer to the general question as well, but
that'd not be blocking.

Cheers,
S.

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