Re: [ietf-provreg] where are we with privacy

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

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

OK.

> 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

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