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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 13 Feb 2003 09:56:54 -0500

> 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:

- 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.

- 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.

I'm not sure that this is a "pick one or the other" situation, 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?

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.

-Scott-

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 13 Feb 2003 14:28:50 -0500

> 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?

> data you are agreeing to my policy".  We have this in the protocol right now

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

> 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

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.)

> We need some real data points to help close the discussion with the IESG.

Agree.

Eric

---

From: "Ram Mohan" <[email-masked]>
Date: Sat, 22 Feb 2003 14:19:52 -0500

>If you're not publishing a data

>We need some real data points to help close the discussion with the IESG.

We're looking into a <dcp> required policy for the .info registry; For the
.org registry, we're also trying to determine the appropriate technical
measures that would make PIR's proposed "OrgCloak" data-protection service
viable.

A session-specific <dcp> mandatory approach is appealing.

-ram
----- Original Message -----
From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>; "Eric Brunner-Williams in Portland
Maine" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 13, 2003 9:56 AM
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 23 Feb 2003 13:56:41 -0500

> measures that would make PIR's proposed "OrgCloak" data-protection service

Good. Let me know if you want my help.

>A session-specific <dcp> mandatory approach is appealing.

I'm glad you think so.

Eric

---

From: Rick Wesson <[email-masked]>
Date: Sun, 23 Feb 2003 11:20:47 -0800 (PST)

Ram,

> A session-specific <dcp> mandatory approach is appealing.

I see how a registry might prefer the <dcp> proposal, however I believe
that the <DoNotDisclose> proposal, where a container allows the
client to set which elements should not be disclosed. Though its simular
to <dcp> It potentially allows the registrant to decide which elements to
protect.

<doNotDisclose>
    <contact:name>
</doNotDisclose>

Also <dcp> requires the policty to be set by the registry, and <dnd>
allows the policy to be set by the registrant.

I believe empowering the registrant is the direction we should take.

best

-rick

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 23 Feb 2003 16:50:36 -0500

Rick,

If rfc3375, sec. 8.4, [1], last sentance read:

   The protocol MUST provide services to identify registrant data
   publication policies.

Instead of:

   The protocol MUST provide services to identify data collection
   policies.

Then we'd share a common requirement statement.

A friendly suggestion: pop some <mumble> into a draft of 3375bis and
get it with some similarly inclined co-authors in before the -00 cut
date.

Then we could discuss if 3375 erred (and we all know the putative error
is mine).

With 3375bis creating a registrant participant in EPP, we can look to
the consequences, or if the scope of registrant-as-actor is limited to
<dnp> values.

Comment #1:

Regardless of the contents of a <dnd> container, it does not allow any
party to state the purpose, recipients, retention period, or access to
the publication data, only some binary property of "disclosure". What
does "disclose" mean?

Comment #2:

The <dcp> we've got has a finite set of elements, each taking attribute
values over a finite set, each with a mechanism to extend the set. I'll
use <glob> to discuss, without unnecessary overspecification, the value
space we're exploring, and who sets these values.

If a <glob> arises from some party other than an EPP client or server,
then it must take on values other than those defined between the EPP
nodes, otherwise it has no independent existance.

	Example: if registrant_A sets <glob> to <1, 2, 3<2,2>>,

		 and <glob> values of <0-I, 0-J, 0-K<0-L,0-M>>
		 are within the repitoire of the registrar/registry,

		 then there is no way of verifying that the registrar
		 didn't set the value of <glob> to a value in its
		 repitoire, in particular, <1, 2, 3<2,2>>.

So, the registrant only becomes "visible" when s/he goes off-reservation
and uses some portion of the value-space that is outside of the operational
practice of the registrar/registry, either because they subset the maximal
defined set of values, or because the registrant extends the maximal
defined set of values.

So, if the registrant creates a <glob> that is outside the space of values
either defined in some standard or operational practice, then the registrant
exists as an independent actor.

So, that's the first awkwardness. The registrant must utter something that
is a complete surprise to the registrar/registry, such as using "00" as a
value for the ccType element, or defining (an extended utility type) a cc5Type
with the length value 5, to allow codes outside of the 639:2 set of values,
e.g., change "US" to "BUSH2".

The second awkwardness is that for the registrant's access policy assertion
to be non-fictional, it has to be capable of binding the conduct of some
other actor, and for the conduct of that actor in varience of that policy
to be detectable.

So, to continue with the ccType example, the registrant would have to be
able to cause an <info> command response to be generated, and in particular,
determine if the contact:postalInfoType's child element either has
a value of "00" or type cc5Type.

Alternatively, for valid values (subsetted by the operational practice of
the registrar/registry), or valid extensions, valid values by the registrant
would result in protocol errors generated by either the EPP client or server.

So, what does a registrant bring to the party, and is it actually worth
having?

Suppose Randy wanted to no-disclosurer for his name as registrant of psg.

If the <dcp> exchange between Tucows and VGRS has
	<recipient><ours/></recipient>
what requirement hasn't been met?

If it is
	<recipient><ours/><public/></recipient>
then Tucows is free to error-out and fail the data propogation to VGRS.

If the <dnd> exchange between Randy and Tucows and VGRS has
	<dnd><contact:name></dnd>
and for reasons discussed above, the semantic of <dnd> is opaque to the
EPP entities, under what set of circumstances could Tucows error out and
fail the data propogation to VGRS? Only if VGRS generated an error? What
if VGRS had an accept-all or refuse-any for non-empty <dcp> elements?

Why do we even need Randy to be involved in this <dnd><contact:name></dnd>?
If Randy can't do anything surprising, then we can whittle his set of
choices down to {0,1}, without loss of generality.

I don't play a lawyer on the net, but there are reasons why 46/95/EC et
seq. has the exposure of the data collection policies of the data collector
as the object of its descriptive focus.

I believe in Satanism, mocking the IESG, depricating the brownie baking
skills of Laura Bush, and that "empowering the registrant" is significantly
harder than beliving in it.

Worst ;-)

Eric