Subject: RE: crypto delay (Notes from Non-meeting)

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 05 Apr 2002 07:41:40 -0500

Of course, but we need requirements for the data as well as
the privacy.  The things Richard and I were discussing were
in fact what the requirements were, not what the solution
was.  There is a requirement that the object include the ability
to translate from lat/lon to planet/country/state/....

Brian

> -----Original Message-----
> From: Randall Gellens [mailto:[email-masked]]
> Sent: Thursday, April 04, 2002 8:37 PM
> To: Rosen, Brian; 'Richard Shockey'; Adam Shostack
> Cc: 'Andrew Daviel'; [email-masked]'
> Subject: RE: crypto delay (Notes from Non-meeting)
> 
> 
> At 5:01 PM -0500 4/3/02, Brian Rosen wrote:
> 
> >I'd love to actually start working on that stuff
> 
> We're required by our charter to do the requirements first.
>

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 06 Apr 2002 17:32:36 -0500

Brian,

Here's how we approached the problem in provreg. I raised the issue, having
blown off a year working on P3P in a prior gig (Engage, where cookies are,
or were, baked), and being then employed by yet another dubious data collector.
Scott Hollenbeck (Verisign), the document editor, took several attempts at the
subject, writing all but the actual MUST requirement (Manditory to Implement).

8.4 Data Collection Requirements

  [1] Some of the data exchanged between a registrar and registry might
  be considered personal, private, or otherwise sensitive.  Disclosure
  of such information might be restricted by laws and/or business
  practices.  The protocol MUST provide services to identify data
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  collection policies.
  ^^^^^^^^^^^^^^^^^^^^

  [2] Some of the social information exchanged between a registrar and
  registry might be required to create, manage, or operate Internet or
  DNS infrastructure facilities, such as zone files.  Such information
  is subject to public disclosure per relevant IETF standards.

Here in geopriv, I suspect the requirement looks more like:

	1. the <mumble> MUST provide a mechanism to or be accessible to
	   mechanisms that map spatial data to territorial jurisdictions

	2. the <mumble> MUST provide a mechanism to identify persistent
	   data collection policies

	3. the <mumble> MUST provide a mechanism to identify transient
	   data collection policies

Thats jurisdictionalization ("j19n" to my friends), PII in the usual priv/
data protection contexts, and state (or delta_{x,y,z}/delta_t).

Now I suspect that the first item is outside the scope of the WG, unless
it wants to find (x,y,z) <-> iso3166 lookup services and define a standard
service interface.

The second is straight forward, and I suggest (from experience) that for
a few minutes Americans assume the EU General and ISDN (or Special) Data
Protection Directives are controlling (a mental exercise), followed by the
OEDC (Japan, etc.) Guidelines, and lastly by US law.

The third is wide-open. Does your handset auto-dial the PD when your delta-v
exceeds the speed limit? 

A general mechanism, or at least an extensible mechanism, or a willingness
to commit to a v1 with some certainty of error and a v2, are worth keeping
in mind.

Cheers,
Eric