Subject: RE: [ietf-provreg] where are we with privacy

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 20 Jan 2003 08:49:36 -0500

> -----Original Message-----
> From: Edward Lewis [mailto:[email-masked]]
> Sent: Sunday, January 19, 2003 9:00 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [ietf-provreg] where are we with privacy
> 
> 
> It's been about a week since we last spent time on privacy.
> 
> It seems to me that we've been asked to put in hooks into the base of 
> the protocol to allow for a generic privacy policy to be stated. 
> Here's why I think we haven't gotten anywhere:

[snip]

What would you suggest as a way forward?

-Scott-

---

From: Edward Lewis <[email-masked]>
Date: Tue, 21 Jan 2003 11:36:52 -0500

>What would you suggest as a way forward?

This is the third try at answering this.  The other attempts got 
lengthy and pointless.

I would like to see a better case made for the granular privacy data 
specification.  The IESG wants it, but the group is not sold that 
this is possible (= worth achieving with the given level of effort 
available).

I would also like others to comment on Jaap's message and assessment that:

At 13:43 +0100 1/10/03, Jaap Akkerhuis wrote:
...
>So yes, the non-disclose attribute will work for us without any
>problem. It is possible that we might do extensions to aid with the
...
>	jaap

I do see that there are some other messages I haven't read yet in the 
mailbox...I've taken too long thinking about this one, I guess.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 21 Jan 2003 14:05:35 -0500

> I would also like others to comment on Jaap's message and assessment that:

OK.

> >problem. It is possible that we might do extensions to aid with the

1. Application of the IESG proposal to "technical" data.

The .NL registry defines (hypothetically of course) a dnp==true value for
one or more elements as an error condition, and presumably returns some
error code.

Someone, Scott if my memory serves, mentioned a registry which defines a
dnp==true value for one or more elements as a non-error, and presumably
returns something other than an error code.

Is using EPP with dcp==true for technical data a good thing? I see it as
an operation to modify the string-space, with no external manifestation,
other than error upon query or transform. I can't imagine an application
to an address registry's operational practices, but I don't have direct
knowledge of address registry or registrar operational art.

2. Application of the IESG proposal to "social" data at a registry.

The .NL registry anticipates (effective 29 Jan 2003) operating under the
general framework of a European Union member state's Data Protection Act.

Consistent with the general framework of EU's Data Protection Directives,
the access, purpose, recipient, and retention are all contractually defined.

This is not generally the case for registries operating outside of the EU,
nor for registrars and resellers operating outside of the EU.

It would be helpful if the details of data protection between a non-EU
resident .NL regsitrar and the .NL registry were available, assuming any
exist.

3. Existance of the PROVREG proposal, in the presence of the IESG proposal.

Would the .NL registry operator use both the session-level <dcp> data, and
the element-level opt-{in|out} data? If the answer is "no", as I suspect
it is, then <dcp> use either a) is error, or b) is silently discarded.
If the answer is "yes", which takes precidence in the event of conflict?

Trying to keep concrete, data originates from a registrant and is collected
by a US-Reseller, and in turn provisioned to a CA-Registrar, and in turn is
provisioned to a .EU-Registry. Is the mechanism that provides the guidance
for operational art at each onward-transport entity out-of-band (contract),
or is it in-band, and if in-band, did the IESG proposal provide the same
policy at each collector/onward-transporter as the European Union member
state's Data Protection Act?

I don't think so.

I could be wrong.

A p|np toggle is fine if purpose/recipient/retention/access are already
taken care of (the Data Protection case). Where they are not, (OEDC and
US cases), a p|np toggle may solve the 954 problem. How it can be applied
to non-954 (and 954bis) is not stated.

Eric

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 21 Jan 2003 18:14:42 -0500

opps. a dot de trops.

s/\.EU/EU/

sorry if anyone was confused.

eric
(who put the "dot" in dotty)

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 21 Jan 2003 19:48:51 -0500

> I would also like others to comment on Jaap's message and assessment that:

OK, part 2.

> >problem. It is possible that we might do extensions to aid with the

\begin{quote}
Deelnemers
...
Deelnemer worden
...
Deelnemers categorie I
	Voor het deelnemerschap categorie I komen in aanmerking
	bedrijven in instellingen die zijn gevestigd op het grondgebied
	van de Euorpese Unie.

	[Category I participation Category I participation is open
	to businesses and institutions based within the European Union.] 

	...

	Het deelnemerschap geeft recht tot:

		o het verzorgen van de registratie van domeinnamen ten
		  behoeve van klanten;

	[Category I participants have the following rights:

		o To apply to register domain names on behalf of
		  clients;]
\end{quote}

The "us" (parties having the capacity to register domain names on behalf
of clients) for which "the non-disclose attribute will work" appears to
be a scoped set of (eventual) EPP participants. The charter for this WG
is not to create a registry-specific, or regime-specific, or jurisdiction-
specific, or object-specific protocol.

How can a registrar signal in-band to a registry that it accepts the general
Data Protection framework, and any specific terms and conditions?

More generally, how can any two (or more) participants in the onward-transport
of customer data signal in-band their data collection practices, and automate
the management of onward-transport?

Eric