Subject: [Geopriv] Questions on pidf-lo

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 11 Nov 2003 11:01:13 -0500

After another reading and some hallway discussions, a few questions on 
PIDF-LO:

1) What's a party?

In the 'retransmission allowed' item, it says "share ... with other 
parties". It is unclear what this means. It probably can't mean 
'transmit on any network link beyond the LR', since the LR may well 
consist of multiple boxes and I don't think we want to rule out that the 
  database is on a different server than the proxy or HTTP server.

On the other hand, does 'party' refer to a legal entity? Thus, if I send 
it to the local Pizza Hut, can that branch send it to HQ?

A reasonable notion may be that this refers to the legal entity that 
owns the domain name where I sent the LO, as that's a matter of public 
(whois) record.

If we want people to respect the rules, we can't have vague definitions 
that leave ample room for creative interpretations or class action lawsuits.

2) External rules

As far as I can tell, the draft is silent on what should happen if the 
ruleset cannot be resolved. I assume the two flags apply, keeping to the 
model of additive permissions.

3) Retention

Normal operating procedure is that databases are backed up. Am I liable 
if a location object accidentally makes it onto the backup tape? 
(Example: retention is 24 hours; LO arrives at 8 pm; backup is run at 
midnight. I can't tell the backup routine to not backup that entry.)

Worded in its current vagueness, I'm afraid that any large entity who 
has any exposure at all would be foolish to accept any object that in 
any way restricts retention and distribution.

Henning

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: John Morris <[email-masked]>
Date: Tue, 11 Nov 2003 12:34:32 -0600

Henning, you won't be happy with how I would answer these questions. 
See inline.  John

At 11:01 AM -0500 11/11/03, Henning Schulzrinne wrote:
>After another reading and some hallway discussions, a few questions 
>on PIDF-LO:
>
>1) What's a party?
>
>consist of multiple boxes and I don't think we want to rule out that 
>the  database is on a different server than the proxy or HTTP server.
>
>On the other hand, does 'party' refer to a legal entity? Thus, if I 
>send it to the local Pizza Hut, can that branch send it to HQ?

If it is the same corporate entity, then I doubt we can do anything 
about this.  But we do not want to suggest that sharing with 
"affiliated" entities is in any way okay.

>owns the domain name where I sent the LO, as that's a matter of 
>public (whois) record.

If I let [email-masked] have my location, that would mean that Time 
Warner could also have it (and presumably use it).   How about 
[email-masked]?   I do not think we want to get into defining as 
"acceptable to disclose to" any entity larger than "[email-masked]." 
Local laws will then govern what joe can do with it vis-a-vis his 
employer.

>If we want people to respect the rules, we can't have vague 
>definitions that leave ample room for creative interpretations or 
>class action lawsuits.

True, but the answer is not to build into geopriv a broad 
interpretation -- if we need to define an interpretation to avoid 
vagueness, then we should define it narrowly.

>
>2) External rules
>
>As far as I can tell, the draft is silent on what should happen if 
>the ruleset cannot be resolved. I assume the two flags apply, 
>keeping to the model of additive permissions.

Although I fully support the model of additive permissions, here I 
think the whole transaction should fail.

>3) Retention
>
>Normal operating procedure is that databases are backed up. Am I 
>liable if a location object accidentally makes it onto the backup 
>tape? (Example: retention is 24 hours; LO arrives at 8 pm; backup is 
>run at midnight. I can't tell the backup routine to not backup that 
>entry.)
>
>Worded in its current vagueness, I'm afraid that any large entity 
>who has any exposure at all would be foolish to accept any object 
>that in any way restricts retention and distribution.

My answer is that big entities will have to cope.  In the U.S. at 
least, we have not yet resolved the train wreck that occurs between 
privacy and routine backup tapes.  If the info is in a backup tape, 
it can be obtained through subpoena, law enforcement request, etc.

And yes, I do think that companies are moving toward a more 
considered backup strategy that takes privacy and other legal 
obligations into account.  It will be a slow transistion, but I think 
it will happen.

So any entity concerned about this type of exposure should decide 
that certain information should simply not be retained in databases 
that are routinely backed up.  I strongly do not think we should 
allow geopriv to say "do not retain the info longer than the rule 
permits (except routine backups don't count)."

>Henning

John

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 11 Nov 2003 14:56:58 -0500

John Morris wrote:

> Henning, you won't be happy with how I would answer these questions. See 
> inline.  John

I'm actually happy with *any* consistent and implementable answer. I'm 
mostly concerned that implementors are given insufficient guidance in 
the spec.

> "affiliated" entities is in any way okay.

Certainly. What would be a good, precise wording for that? I suspect 
that the existing privacy laws have to make the same distinction between 
the corporate entity and affiliates.

> 
> If I let [email-masked] have my location, that would mean that Time Warner 
> could also have it (and presumably use it).   How about [email-masked]?   
> I do not think we want to get into defining as "acceptable to disclose 
> to" any entity larger than "[email-masked]." Local laws will then govern 
> what joe can do with it vis-a-vis his employer.

There seem to be two cases: customer-to-customer communications, which 
the ISP has no business in looking at and customer-to-corporation 
communications, which the corporate entity needs to know what to do 
with. This can't be left to the guessing of the implementor. We can't 
write a law here, but something a little less vague than 'party' is needed.

> 
> True, but the answer is not to build into geopriv a broad interpretation 
> -- if we need to define an interpretation to avoid vagueness, then we 
> should define it narrowly.

I fully agree. I'd be very happy with very narrow definitions. While it 
may be reasonably clear what it means to send a LO to [email-masked], 
it's far less clear what it means if the using protocol is HTTP and I 
upload this via SOAP to http://www.aaa.org.

One way to phrase this is that disclosure is ok if it is directly 
related to the intent of the service request. If I send a presence 
update to John, AOL has no need to hand this to Time Warner Books to 
service the request. Similarly, if I hand my location to a towing truck 
request service, AAA has no need without permission to hand this to 
their travel agency.

> Although I fully support the model of additive permissions, here I think 
> the whole transaction should fail.

Either way, this needs to be clearly spelled out.

> 
> My answer is that big entities will have to cope.  In the U.S. at least, 
> we have not yet resolved the train wreck that occurs between privacy and 
> routine backup tapes.  If the info is in a backup tape, it can be 
> obtained through subpoena, law enforcement request, etc.
> 
> And yes, I do think that companies are moving toward a more considered 
> backup strategy that takes privacy and other legal obligations into 
> account.  It will be a slow transistion, but I think it will happen.
> 
> So any entity concerned about this type of exposure should decide that 
> certain information should simply not be retained in databases that are 
> routinely backed up.  I strongly do not think we should allow geopriv to 
> say "do not retain the info longer than the rule permits (except routine 
> backups don't count)."

As long as we say "this includes backup media", I'm fine - I'm just for 
clarity. We can't remove every ambiguity, but that's no excuse not to be 
precise where we can.