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

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

> > 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?"
> 
> No.  This will result in a failure to create, not a successful response.

My point was, you've designed a query mechanism, and what looks like a two
command sequence.

> > is different from
> > "What is done with data provisioned?"
> 
> Yes. This is the intent.  Public means that the info will be published to
> the WHOIS, and Private means that it will be hidden.  The current mechanism
> is this simple.

Well, not-via-:43 is clear. "private" and "public" are terms of art that
resist unambiguous specification.

> > or less the same session, you've not solved for the day when policies do
> > in fact change.
> 
> So you are saying that the server should perhaps queue a msg for the client
> if policies are to be changed?... or something in-band to announce to the
> clients?

I point out that there is a temporal property contained in the <dcp>, that
the retention period of the data (and the policies announced when the server
announces its availability to collect data) is known to the client (along
with anything else that might be in a <dcp>, prior to the client submitting
data to the server.

> > 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.
> 
> Just thought it seems to make a bit more sense in a practical environment.
> For example, when I look at a ccTLD, they will be putting out a public
> statement or even consultation paper or something before they change their
> policies,

Sense? Practicality? Taste varies. I'd like to automate privacy/datacollection
handling in registration systems.

> > If the temporal properties of policies are better communicated
> out-of-band,
> > why are the semantic properties of policies better communicated in-band?
> 
> Because of 2 things:
> 
> 1. the client needs to know what (which info item) exactly they can manage
> (public/private)
> 2. they can toggle public/private on the aspects that are allowed to be
> optional

But with no guarantee that the policies will be consistent between any two
consequtive registrations.

> > 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.
> 
> So perhaps it is good to extend the check command as well to return the
> policy statements so that clients will know what they are getting into
> beforehand...

Back to the two-step. Familiar to registrars who want to know if a <create>
of "somewellknownname" will fail, before attempting it.

<check><create>.

Not significantly different from

<create><update> (and optionally, if disapointed, <delete>).

> > 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.
> 
> dcp should be good to deal with the purpose and stuff.  My proposal aims to
> make an effort to allow granular management of information privacy.  We
> could extend the tags so that each facet can be further optionally bound by
> multiple policies based on the usage of data.  Also, I think you are right,
> perhaps the info response should be a bit different and allow the client to
> query for only the privacy policy elements and not return the entire glob
> everytime.  I will make that change.

<info><create>.

Eric