Re: [ietf-provreg] Our "Privacy Issue"

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

...
> The protocol must provide a mechanism to allow enforcement

OK. We blew it semantically in the grrq when we stated the req as a
mechanism to announce.

>                                                            of privacy
> policy at either the registrar or registrant.

OK. We blew it semantically in the grrq when we limited the protocol to
registrars and registries.

>                                                This must be done in a
> protocol feature that is "mandatory to implement, optional to use."

No comment.

> Further, the privacy meta-data must be to individual elements of
> social data.

OK. We blew it syntactically by reference to an inextensible type.

> ...  this is what we need to solve ...

I disagree with the claim that any IETF WG needs to be responsive to the
IESG. The claim only begins to approximate "true" iff the WG wants IESG
approval of its work-product.

I'm not convinced that the issue of contention is technical.


> As EPP stands now, privacy policy decisions are only possible at the 
> registrar.  This is because the dcp element allows the registry to 
> tell the registrar the "rules."  Whatever the registrar sends to the 
> registry is considered to be in accordance with the rules.

Correct. The registry announces a session-policy. Implementors are free
to evaluate the registry-announced policy, and implement local policy,
e.g., accept the policy and propogate policied data, or decline.

> What is desired is a mechanism that will let EPP support thick 
> registries, in which social data is held by the registry.

Umm, this _is_ the current model, neh?

>                                                            In such 
> situations, the registrar needs to inform the registry of 
> restrictions on the redistribution of the data submitted to the 
> registry.

This does not follow. Where state is persistent is a different issue
from how may access to that persistent state be implemented.

Just to test the correctness of this reasoning however, if there did
exist a mechanism for a client to select from a menu of policies in
a <dcp> (this begins to look like beep and the srv record), and the
menu offered by a registry was _in_theory_exhaustive_, would the
registrar need to do anything more exciting than pick a policy out of
the extended hat?

> There's one protocol standards consideration I'd like to make.  The 
> more detail and depth in the solution of a problem often leads to a 
> tougher job in reaching consensus.  I.e., as a chair, I appreciate 
> efforts to refine and divine the depths of privacy, but such threads 
> are in danger of becoming distractions to the main job of this WG.

I'll be _happy_ to leave the problem to more capable hands than my own.

To me, it _was_ just distributed read and write access mechanisms to
shared store, with a specific syntax. If someone claims read-on-43
exhaustively defines "privacy", I don't care. It doesn't exhaustively
define _read_.

Enforcement is a whole different can of worms, unless this is just a
techno-fiction.

> For procedural 
> reasons, I'm not going to mention that proposal until the problem 
> statement is accepted by the WG (i.e., the mailing list).

Nope. Seems technically flawed to me, and worse than what we had.

YMMV.

Eric