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

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

>                                                      Apparently you 
> are not happy with requiring the protocol let the client include 
> privacy meta-data to achieve the goal of allowing enforcement to 
> happen at the server.

Actually, I don't even know what "enforcement" means.

How is "enforcement" meaningfully defined in the protocol?

If EPP allowed unconditional write-access to a centralized store, with
only an auth-thingie to partition the store into N-registrar buckets,
and allowed each writer to write the read-access (general, a la :43,
or to any other registrar writer, or the blind registry store manager),
then I'd have a clue what "enforcement" might mean.

The registrar would hand a bitmask the size of a contact object to the
registry, and could attempt to modify it without the auth-thingie, or
read it back without the auth-thingie. Partial sight proved.

>                                                      Apparently you
> are not happy with requiring the protocol let the client include
> privacy meta-data

If only it were that simple. 

All I'm looking for is a way to distinguish one policied endpoint from
another. What I'm not looking for is a way to change the policy on one
policied endpoint, until it is indistinguishable from another.

>                                                      Apparently you
> are not happy with requiring the protocol let the client include
> privacy meta-data

But it isn't that simple, is it? If it were, then just sourcing the <dcp>
from the client, and sinking it at the server, would suffice. But that
isn't it.

Hey, we could go back to BNF, or whatever the people use who write the
UI stuff for insurance companies, and add a little check box. For some
reason, the extra bit(s) have to be just so.

> >Are there any success or failure semantics? Is the transaction atomic and
> >unitary, or is a partial write success?
> 
> It's all policy as far as we can tell.

No that is interesting. A functional requirement with no semantics.
A mechanism with no discernable effect. Now that is worth the price of
admission.

> >Is the new semantic capable of test by any in-protocol means?
> 
> Well, we want to be able to set, check, change and define the meaning 
> of absence.

Sounds like an abstract, post-creat, access provisioning protocol, for
shared, multi-reader repositories. 

Not the same as getting the data past creat, or mod, or ...

Eric