Re: [ietf-provreg] provreg's privacy issue

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

> Good to hear that you have read my stuff. :-)

No one reads mine, so I'll stop writing it and read yours, its the worst
I can do ;-)

> It is a bit bulky right now.

I'll send you what I did to de-xml-ize p3p policies on cookies, where overhead
did matter. Here however, overhead shouldn't. But don't optimize too early ...

> > o a bi-di glob on <update>!!!
> 
> bi-di glob??... what do you mean?

On both command and response. This is where the action is. Who cares if the
server <info> and <create> responses have new glop? What counts is if by a
write (here <update>) against the shared store (here registry) manages to
either fail to error (glop accepted by registry as some policy description,
considered by registry to be "valid"), or can generate a change in the glop
that comes back in any response. If none, then either the registry had the
"right" policy already, or ignored the attempted policing of data previously
provisioned in the client <create> (and nominally annotated in the new glop
in the <create> repsponse).

> I do not understand why it does not apply to the WHOIS...

It does, but there are some loopholes.

> ... from the <create> response I will know which contact info I will
> need to disclose and which ones will be hidden and which ones I can
> later optionally opt-in or out ...

So you see this as a field query mechanism.  Fine.

> ... it just allows the registry to annouce its policies ...

	"Which fields are manditory to fill in?"
is different from
	"What is done with data provisioned?"

> What do you mean?  Do you mean that the registry advertises that the client
> may choose to make phone# private yet not allow it to change the status to
> private?  If so, then the registry system is broken...
>
>> Now what happens?
>
> If the registry nacks the status=private operation later because of change
> of policy, then there should be probably be out-of-band communication to
> announce to all users, also, the client can always do a domain info to check
> the status and current registry policy for each info item.

Yes I do. To be concrete, domains are sold by the COM/NET registry to a set
of registrars, for periods of up to 10 years. What are the temporal properties
of policy guarantees? If you assume a place-holder create, followed by the
"real" create, more or less in the same session, or a real create, followed
by a series of updates to "tune" the privacy policy to taste, again in more
or less the same session, you've not solved for the day when policies do in
fact change.

But you thought that through, and decided that the temporal properties of
polices is better communicated out-of-band, so they could in fact change
without in-band notice.

If the temporal properties of policies are better communicated out-of-band,
why are the semantic properties of policies better communicated in-band?

> > Why "discover" access policy _after_ a committing a write?
> 
> Please clarify what you mean?

Your proposal makes no reliance upon any policy information from the
registry. You've proposed a momentary capabilities check arising from
a <create> command, but you only get the data in the response.

Therefore, either each <create> command is preceeded by some command who's
side effect is to discover the present policy, or each <create> command is
followed by a series of one or more <update> commands to conform the policy
(applicable to some specific object) at the server to the policy goal held
by the client.

Its a hell of a lot easier to simply have the server announce its policy,
and if a mechanism is necessary to select some set of values from some
range of values (and I'm referring to purpose, recipient, retention and
so forth, as well as which field in the contact object is optional), to
get on with its specification, than finding it after assuming it even
exists.

Eric

P.S. Get rid of everything except the <update> glop. <create>, <update>,
test <update> response, repeat until correct, or failure. Upon failure,
issue <delete>. If <delete> fails, issue <update> with the personal data
of the registry CEO, or the current ICANN CEO, depending on one's sense
of humor.

P.P.S. This only solves for WHOIS, not for any other purpose, mechanism,
or period, to which provisioned data may be used without prior disclosure
and informed consent, or at least the opportunity to form same, buy the
registrar, and presumbly the parties it acts on behalf of.

P.P.P.S. Cheers!