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

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

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