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

["Edmon Chung" <edmon@neteka.com>]

Hi Eric,

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <brunner@nic-naa.net>
> 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
...

That will be great.  Yeah, we were thinking that we should maintain
flexibility first and then optimize later (in fact, our actual
implementation is much leaner... but because this was intended to be a
protocol discussion, we made it a bit more extensible. and thus, larger
overhead.

> > 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?"

No.  This will result in a failure to create, not a successful response.

> 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.

> 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.

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?

> 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,

> 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

> 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...

> 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.

Edmon