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

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 17 Dec 2015 04:55:27 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-clue-framework-24: No Objection

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-clue-framework/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for a pretty comprehensive description. These sound like
fun systems on which to work. 

Pity there are so many IPR declarations with not great terms and
for something that to me at least doesn't appear to require
invention (just construction of existing bits) but I guess that's
the world we live in and the WG were ok with that.

- 7.1.1.3 - I wondered if the "MUST be co-planar" requirement
could cause issues (bugs) if receivers don't check for that. Are
receivers expected to verify that on receipt or is the MUST only
for senders?

- 7.1.1.10: privacy issues abound, but section 15 only refers to
the communications security aspect. I think you ought recommend
that implementations SHOULD minimise the information sent, and
SHOULD give users control over what is sent. You might want to
note the utility of sending the same subset of information for
regular repeated calls but I'm not sure what clue protocol might
know that calls are repeats or if there's a better way to manage
re-use of privacy settings for users.

- The secdir review [1] noted some issues that may be worth
considering for later WG documents. I'd encourage folks to try
get in touch with the reviewer when doing later work as that
might avoid some late-surprises. (That is not a threat btw, just
encouragement to try take advantage of a reviewer who likes to
consider more than just what's in front of him today:-)

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06244.html

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 22 Dec 2015 15:50:45 -0800

Hello Stephen,
I have a few responses below.
Mark

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Thursday, December 17, 2015 7:55 AM
[Duckworth, Mark] Everything in an advertisement could cause issues (bugs) if the Provider puts incorrect information in it. There are many possible ways an advertisement can be internally inconsistent. In the CLUE protocol document it defines a "Conflicting values" error code, which a message recipient can send back to the sender if the recipient detects an error in the message.

> re-use of privacy settings for users.
[Duckworth, Mark] I makes sense to me to add a statement like "an implementation SHOULD give users control over what sensitive information is sent in an Advertisement." But I don't think we should say "SHOULD minimize the information sent", because that would defeat the purpose of including that information in the protocol in the first place.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 22 Dec 2015 23:57:45 +0000

Hiya,

On 22/12/15 23:50, Duckworth, Mark wrote:
> Hello Stephen, I have a few responses below. Mark
> 
>> -----Original Message----- From: Stephen Farrell
>> [mailto:[email-masked]] Sent: Thursday, December 17,
>> 2015 7:55 AM 
>> - 7.1.1.3 - I wondered if the "MUST be co-planar" requirement could
>> cause issues (bugs) if receivers don't check for that. Are 
> [Duckworth, Mark] Everything in an advertisement could cause issues
> (bugs) if the Provider puts incorrect information in it. There are
> many possible ways an advertisement can be internally inconsistent.
> In the CLUE protocol document it defines a "Conflicting values" error
> code, which a message recipient can send back to the sender if the
> recipient detects an error in the message.

Fair enough. OTOH, I'm still no clearer if the spec is calling
for the MUST to be enforced by recipients or not. Don't you think
the document ought say that explicitly? I do, FWIW.

>> SHOULD give users control over what is sent. You might want to note
>> the utility of sending the same subset of information for regular
>> repeated calls but I'm not sure what clue protocol might know that
>> calls are repeats or if there's a better way to manage re-use of
>> privacy settings for users.
> [Duckworth, Mark] I makes sense to me to add a statement like "an
> implementation SHOULD give users control over what sensitive
> information is sent in an Advertisement." 

Great.

> But I don't think we should
> say "SHOULD minimize the information sent", because that would defeat
> the purpose of including that information in the protocol in the
> first place.

I disagree fwiw, but that may be down to different interpretations
of what minimise means. To me, it means "only send what's needed to
get what you want to happen" and "as a receiver, don't expect senders
to include information you don't really need." Taking that meaning,
I'm not sure how one could really oppose data minimisation and be
privacy friendly tbh.

Cheers,
S.

>> considering for later WG documents. I'd encourage folks to try get
>> in touch with the reviewer when doing later work as that might
>> avoid some late-surprises. (That is not a threat btw, just 
>> [1]
>> https://www.ietf.org/mail-archive/web/secdir/current/msg06244.html
>> 
>

---

From: Christian Groves <[email-masked]>
Date: Wed, 23 Dec 2015 13:42:57 +1100

Hello Stephen,

Please see below my comment below marked [CNG].

> I'm not sure how one could really oppose data minimisation and be
[CNG] I would tend to agree with Mark. The point of CLUE is that an 
endpoint advertises information, the consumer decides what's relevant to 
it. The advertisement is not asking the consumer to do anything or 
asking the consumer to make something happen. The endpoint advertises 
the information it has. The consumer chooses what information is 
relevant to it for the selection and presentation of captures. One 
consumer may find the fact that knowing a capture contains the "chair" 
useful, another may not. The advertiser isn't in a place to figure this 
out.

Regards, Christian
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 23 Dec 2015 03:04:04 +0000

Hi,
Please see inline,
Stephan

>the document ought say that explicitly? I do, FWIW.

The whole section 7 (obviously including 7.1.1.3), and sections 8 and 9, are intentionally written as a data structure specification only.  I would hate breaking this clean (I think) doc structure by introducing senders or receivers. 

One way to give Stephen what he wants without breaking the doc structure as described above would be to add a sentence like “An Area of Capture attribute where the four points are not co-planar is undefined; the attribute’s values MUST be ignored and handled as if the attribute were not available, except for error handling (i.e. reporting inconsistent values)."

>I'm not sure how one could really oppose data minimisation and be

Generally speaking, the xCard info about which this section is concerned about is not required to make anything “work” protocol-wise.  It’s fully optional metadata.  However, it’s often useful metadata.  For example, when you have a three way conference with six people per room (for a total of 12 people visible on each room’s screen), it’s useful to know the names of those people, because you may not know all of them by name and you want to be able to address them directly in a conversation, rather than say “the lady who spoke next to last".  That’s why most (all?) of today’s non-standard implementations of telepresence allow to, as the minimum, something like names and locations of the participants somewhere overlaid on the decoded windows.  Quite often, there is also a user-interface outside the main telepresence screens, on which one could have side conversations through text chat etc.  On those user interfaces, often, email addresses and similar info is available.  That’s what this xCard info is used for.  So if you interpret “work” broadly, then yes, the xCard metadata is necessary to make the system work (“work" being defined as being useful to the users).

When we started with the framework, I believe to recall we had initially simple code points like a string for the name and another for the location.  However, we opted to generalize that using xCard.  

How the xCards are populated is an entirely different story.  It’s a policy thing.  For example, when using telepresence in an enterprise, conceivably, scripting by the IT department would populate the xCard with all info available in the company phonebook, to ensure the most productive meeting.  Let the receiving users sort out what they want to see displayed, and what not.  However, when the same telepresence room “dials” out to a different firm, certainly confidential information such as internal reporting structures, paygrades, and perhaps even phone numbers and whatnot would be omitted.  Again, scripting by IT would ensure that.  If the same room were used after-hours for a meeting of anonymous alcoholics groups, clearly, one would not populate the xCard at all, and that would probably be somewhere in the advanced settings in the user interface (and someone who books a telepresence room for such a meeting better be qualified to tinker with those settings).  

So yes, Mark is right, it’s entirely a user’s choice what to send, if you define “user” broadly enough.  Going further, it’s also the user’s choice what to do with received info.

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 23 Dec 2015 10:25:51 +0000

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.

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.

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 23 Dec 2015 18:09:12 +0000

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.

>real protocol design issues there as well as implementation

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