Re: [ietf-provreg] FYI: EPP implementation by the Polish registry

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

> 
> > This is a good request.  This is one of the missing pieces of the 
> > converstation.
> > 
> > At 11:02 -0500 2/11/03, Eric Brunner-Williams in Portland Maine wrote:
> > >>  The WG should note that implementers of real-world 
> > privacy policies are
> > >>  finding it necessary to add a "do not disclose" element.
> > >
> > >Could someone, possibly an implementor, comment on the 
> > design choice that
> > >did not utilize the <dcp> element, and disclose its 
> > deficiencies? I can
> > >guess, but it would be nice to hear from someone else who 
> > considered it
> > >and found it failed to meet a requirement.
> 
> Is Eric's request behind a thought that we are considering either the
> current DCP functionality, or the "do not disclose"-proposed functionality,
> but not both?  I can easily see a need for both:

I'm a little more transparent than that. Jay Random-Implementor decided to
do something novel.

However, assume non-uniqueness of mechanism, and non-uniformity of existence,
with no fewer than one mechanism defined to be "manditory to implement". What
results are forseeable, asumming anything can be forseen?

> - in some environments, it might be OK for the server operator to say "this
> is what I will/might do with data, and if you as data originator give me
> data you are agreeing to my policy".  We have this in the protocol right now
> with the <dcp> element.

Agreed. The announced data collection policy of the server allows the client
to policy-based selection among servers.

> - in other environments, it might be OK for the data owner to say "this is
> what I will allow you as server operator to do with the data I share with
> you".  I thought some of the European contributors have said this sort of
> functionality is required under recent European privacy laws.  This is
> something we don't currently have in the protocol.

Disagree. The <dcp> states the purpose, recipients, access-right (of the data
owner), and retention period, of the policed session in which some data will
conditionally flow. For a server to offer <dcp1> ... <dcpN>, it need only
cycle these through a fairly small value-space to find the least-restrictive
policy to which the client (and presumably the registrant) are willing to
accept. APPEL attempts this, and the P3P WG attempted, and abandoned for 1.0,
a negociation or owner-preference signaling mechanism.

The EU DP policy requirement contributions to the W3C's P3P WG and to ccTLD
registry operators, and/or gTLD interested parties, could be different.

> I'm not sure that this is a "pick one or the other" situation,

Disagree. See above. Manditory beats optional (IESG's point), regardless of
utility.

>                                                           ...  but I'm also
> interested in implementer perspectives.  If you're not publishing a data
> collection policy, is there any specific issue that's driving that decision?

Agree.

I can understand why a company operating under the jurisdiction of the FTC
would NOT want to go beyond the regulatory minima specific to its industry,
as to do so would create an unnecessary duty <not a lawyer, etc.>, or take
the opt-in side, before it (ever) becomes law. 

I can understand why a company operating under the jurisdiction of ICANN
would NOT want to suggest that the ICANN WHOIS TF profoundly lacks clue.
(Their latest proposal requires registrants to respond to postal or fax
spam, not just email spam.)

> I haven't decided what makes sense for the .com and .net registry yet, but
> other people who are using EPP in domain registry operations must have been
> through a decision process.  Come on, people, please let us know what you're
> doing with respect to privacy and data collection and why you're doing it!
> We need some real data points to help close the discussion with the IESG.

Agree.

Eric