Subject: Re: [clue] Stephen Farrell's No Objection on draft-ietf-clue-framework-24: (with COMMENT)

From: Christian Groves <[email-masked]>
Date: Mon, 4 Jan 2016 13:50:33 +1100

Hello,

+1 on Stephan W's response. I also think this is a policy issue rather 
than a protocol issue.

Regards, Christian

On 24/12/2015 5:09 AM, Stephan Wenger wrote:
> Hi Stephen, all,
> Pruning the distribution list, as this appears to be a post facto discussion with respect to the framework document, and I don’t want to waste the bandwidth of the IESG folks.
>
>
>
>
> On 12/23/15, 02:25, "Stephen Farrell" <[email-masked]> wrote:
>
>> Hi all,
>>
>> On 23/12/15 03:04, Stephan Wenger wrote:
>>> I do not believe there is any value in documenting the above choices.
>>> The options are known and understood in the industry at large, and by
>>> reasonably competent people.
>> I'll just note that the industry at large has IMO not yet done
>> a good job on privacy, with e.g. user agents automatically
>> re-sending data every time, once the data was entered or
>> approved for sending once. (Yes, doing better has UI implications,
>> but that's just a part of doing a good job.)
>>
>> And I consider the pushback from the authors here as a part of
>> that - we need to get better at really considering privacy and
>> at not just assuming that sending more data might be useful
>> sometime and hence ought be done, just-in-case.
>>
>> In this case, I can imagine they may be tricky privacy issues
>> to be considered as people join and leave calls. E.g. would
>> Stephan's enterprise admin like all their employees to include
>> job titles and business unit information in a call that involves
>> outsiders? What if an outsider joins in the middle? And the same
>> issues can come up where real privacy (a human and not corporate
>> concept:-) is at issue, if I'm on a call with people with whom
>> I'm happy to share location information and then a newcomer
>> joins, what should I (or others) tell them? I think there may be
>> real protocol design issues there as well as implementation
>> issues.
> No, I don’t think there is a "real protocol design issue”.  There are certainly policy issues.  Depending on your viewpoint re privacy vs. usability (on which we obviously have different opinions), there may be implementation issues.  But I doubt there are protocol issues.  And, for the framework, there is no issue at all.
>
> Let me explain by starting with the last statement.  As I mentioned earlier (although in a different context), the relevant part of the framework defines a data structure, but not how that data structure is populated, except in a handful of cases (like the co-planar points in the area of capture), none of which appear to have privacy issues.  The xCard attribute is optional, and within the xCard spec, all fields are optional but the real name IIRC.  Unless you want to enforce a privacy policy by data structure design, there is no point to normatively specify anything here beyond hwat is already specified.   We can (and now have) drawn special attention to the Xcard in the framework doc, and we do that even more so in the data model doc (which fleshes out the details of the data structures.  The security consideration section of the data model doc already mentions initial requirements resulting from the potential use of xCard, though those are not fully fleshed out yet (so please don’t beat up Roberta and Simon just now :-).  I’m sure the current discussion will lead to an improvement there, which is in part why I continue to beat up this dead horse.
>   
>
> As far as the protocol goes, I don’t think there are protocol design issues.  It’s absolutely supported by the current design that a room full of anonymous alcoholics joins an existing intra-enterprise call, and does not send their xCard info, nor receives the xCards from the other rooms.  All advertisements are sent point-to-point (no multicast distribution), and all can be hand-tailored to fulfill the needs of the respective recipients.  Nowhere it is stated that all attributes in all advertisements sent to all endpoints have to be all the same.  So the protocol should not have a “real protocol design issue” with respect to xCards, right?
>
> Stephan
>
>> But, none of this is blocking now so by all means go ahead but I
>> do think we are missing a good opportunity to provide guidance
>> here in a framework document that might cause those writing
>> protocol specifications and implementations to stop and think
>> about privacy when they otherwise might not.
>>
>> S.
>>
>> PS: None of the above is meant to imply that we're bad at
>> privacy for nefarious reasons - I mostly do not think that is
>> the case, it's just a thing we need to get better at.
>>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue