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

From: Edward Lewis <[email-masked]>
Date: Mon, 10 Mar 2003 08:08:29 -0800

In response to the IESG comment:

     why do domain/contact/.. not have granular information about privacy?

The provreg WG has apparently reached consensus upon this suggestion:

     That being the case, my preference would be to put _all_ of the DNP
     syntax and semantics into an extension (where the problem can be
     addressed as a whole) while making the existing DCP element mandatory
     if that resolves the privacy issue with the IESG.

For the WG, Scott Hollenbeck will make the necessary changes to the 
base specification to reflect this consensus.  (Scott: please do this 
as soon as you get the chance.[0])  It would help the IESG to see the 
formalized text based on this.

Returning to the IESG review of these documents sometime around 
October, we feel that we have addressed all of the comments now.  As 
soon as the new documents hit the repository, we ask that the IESG 
resume its review of the specifications.

[0] Yeah, I realize that drafts submissions are being held up until 
after the IETF meeting week.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 10 Mar 2003 19:15:21 +0100

On måndag, mar 10, 2003, at 17:08 Europe/Stockholm, Edward Lewis wrote:

> October, we feel that we have addressed all of the comments now.

Also the one from Allison which sort of disappeared in the flurry of 
other discussions?

> As soon as the new documents hit the repository, we ask that the IESG 

Thanks!

   paf

---

From: Edward Lewis <[email-masked]>
Date: Mon, 10 Mar 2003 10:46:49 -0800

At 19:15 +0100 3/10/03, Patrik Fältström wrote:
>>  Returning to the IESG review of these documents sometime around October, we
>>feel that we have addressed all of the comments now.
>
>Also the one from Allison which sort of disappeared in the flurry of other
>discussions?

We 'think' we addressed that issue long ago, the answer to it should 
already be in the specs in the repository.

Perhaps it would be good to prepare a summary of answers to the IESG comments.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 10 Mar 2003 13:50:10 -0500

I guess I missed Allison's note. It wasn't the one in reply to Rick, right?

---

From: Edward Lewis <[email-masked]>
Date: Mon, 10 Mar 2003 11:18:52 -0800

>I guess I missed Allison's note. It wasn't the one in reply to Rick, right?

http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00114.html

(Is that what you need?)

---

From: "Edmon Chung" <[email-masked]>
Date: Wed, 19 Mar 2003 15:59:57 -0500

Hi,

----- Original Message -----
From: "Edward Lewis" <[email-masked]>
>      why do domain/contact/.. not have granular information about privacy?

I am not sure if the draft that I am working on would help:

http://ner2r.com/draft-ietf-provreg-epp-privacy-00.txt

The document proposes an EPP extension to handle Domain Contact Privacy
Profiles and is kept extremely flexible so that it should be able to adopt
to registry mandated or client enforced/suggested privacy profiles.
It basically describes a private/public toggle for as well as a way to
announce registry policy on each attribute of each contact in a domain name.

This is in fact something similar to what we have implemented for a client.
Mainly for what contact info could/must be published through the WHOIS.

One thing that this current draft has not addressed is if there needs to be
different types of disclosure to different types of querying entities.  But
could be added by allowing multiple policies and to add a policy type
attribute.

Have to admit however that the bulk of the wordings in the document itself
was stolen from Scott's enum draft.  Well... I think Scott did a good job in
providing a great template for EPP extension docs. :-)

Edmon

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 19 Mar 2003 18:39:08 -0500

Edmon, Henry,

Some text, on this list, before going off into the delirium of boiler-plate,
would have been a blessing, neh?

I see ...
	o a glob going from registry to registrar (don't tell the iesg),
	o a glob on <info> response, approximately 1k in size,
	o a glob on <create> response, ditto,
	o a bi-di glob on <update>!!!

I see ...
	o a BEGIN END section of formal syntax with very, very little text
	  seperating these delimeters (don't worry, we haven't gotten even
	  a syntax clue from the IESG),

I see ...
	o a totally irrelevent i18n section, but I understand, this is one
	  of Neteka's sweet spots (besides, the IESG will surely appreciate
	  the suggestion that XML will melt if "private parts" is written
	  in Chinese, and the Chinese characters encoded in Big5),

I see ...
	o two hooks parked at the IANA to hang some coats on, fine.

So, the inference from the examples is that the syntax is a restatement of
a big bit of the contact object, putting a binary, or enumerated set of
value against each element -- sort of pervasive, but restricted to the
contact object, attributes (but as an additional carried along "shadow"
of the original, unencumbered contact object.

Not only does this NOT do what our Masters in Moscow, the IESG, require,
(the glob goes in the wrong direction), the scope of the extension, as
it is from registry to registrar, cannot apply to any instance of WHOIS
operated by the registry.

Here's my you-pay-for-dinner question:

	registrar_N (Neteka) initiates a session with registry_V,

	registry_V ships back a <dcp> that says 95/46/EC applies
	and all data is not repurposed, there are no recipients
	other than the registry, that it retains the data only
	for the period of registration, plus some operational window
	for the purpose of renewal, and ... everything is _private_
	(except publication via 1034/35).

What data collection / privacy problem remains (that your proposal
cleverly solves)?

Heck, lets go for two dinners, there are two of you anyway:

	registrar_N (Neteka) initiates a session with registry_V,

	registry_V ships back a <dcp> that says says anything you want,
	even no <dcp> at all,

	registrar_N does a create for mumble,
	registry_V acks appropriately

	registrar_N ships an update on mumble that attempts to set a bit,
	e.g., don't publish phone #, provisioned in the prior op,

	registry_V nacks inappropriately, and in bad taste.

Now what happens?

Why "discover" access policy _after_ a committing a write?

There is an Americn idiom about closing a barn door _after_ the horses
have left.

I'm always lacking clue,
Eric

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 19 Mar 2003 18:53:11 -0500

> this is quite incorrect, you just didn't like it.

Am I that shallow? Well, a pointer to the item with a substantive proposal
would be nice.

Eric

---

From: Randy Bush <[email-masked]>
Date: Wed, 19 Mar 2003 15:45:56 -0800

once again, data structures 101 sez that each attribute would have
a privacy tag, as opposed to a blob of tags at the front.  but, as
far as i am aware, no one on the iesg cares that much about the
syntax, it's the privacy semantics which ran aground.

randy

---

From: "Edmon Chung" <[email-masked]>
Date: Wed, 19 Mar 2003 21:30:35 -0500

Hi Eric,

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

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
To
> would have been a blessing, neh?

This reflects some of the things we have done for a particular client.  I
saw some discussion in the group earlier about possibly having an extension
and a public/private toggle type thinking and thought this could be a
starting point.

> o a glob on <info> response, approximately 1k in size,

It is a bit bulky right now.  but really it is whether this concept is good
that is the discussion... we could make it a bit more efficient, but will
loose some flexibility.  We could make it much more efficient if we could
incorporated it directly into domain mapping...

> o a bi-di glob on <update>!!!

bi-di glob??... what do you mean?

> o two hooks parked at the IANA to hang some coats on, fine.

Ok.  Will take these away in the submission.  I was just doing a plain copy
and "search and replace". :-)

> operated by the registry.

I do not understand why it does not apply to the WHOIS... if the info is
deemed to be "public" it is published, if it is "private" it is not
published at the WHOIS.

> What data collection / privacy problem remains (that your proposal

While I am not familiar with 95/46/EC, I think at the least, 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.  I dont think it "cleverly" solves anything, it just allows the
registry to annouce its policies as well as the client to specify its
preferences.

> registry_V nacks inappropriately, and in bad taste.

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.

> Why "discover" access policy _after_ a committing a write?

Please clarify what you mean?

Edmon

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 20 Mar 2003 00:07:50 -0500

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

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

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

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

---

From: "Edmon Chung" <[email-masked]>
Date: Thu, 20 Mar 2003 11:57:05 -0500

Hi Eric,

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

> "Which fields are manditory to fill in?"

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

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

> or less the same session, you've not solved for the day when policies do
in

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?

> polices is better communicated out-of-band, so they could in fact change

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,

> 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

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

> get on with its specification, than finding it after assuming it even

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

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 20 Mar 2003 17:00:33 -0500

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

> the WHOIS, and Private means that it will be hidden.  The current mechanism

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

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.

> statement or even consultation paper or something before they change their

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

> 2. they can toggle public/private on the aspects that are allowed to be

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

> policy statements so that clients will know what they are getting into

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

> everytime.  I will make that change.

<info><create>.

Eric

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 21 Mar 2003 10:51:29 -0500

Randy, and anyone else with a view,

> a privacy tag, ...
> ...
> ... it's the privacy semantics which ran aground.

In the abstract, there exists at least two distinct values that an
algorithmic evaluation of a variable may yeild.

Ignoring everything else, is the IESG's guidance on this subject,  
that the set of values for which any algorithmic evaluation of a
privacy tag is exactly two? If it is not exactly two, what is the
exact characterization of the value space?

Thanks in advance,
Eric

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 21 Mar 2003 10:51:33 -0500

> a privacy tag, as opposed to a blob of tags at the front.

In the abstract, there exists at least one type definition hierarchy.
At least one hierarchy is non-degenerate, and the "primitive" and
"constructed" model of derivation exists.

Ignoring everything else, is the IESG's guidance on this subject,
that the type definition hierarchies contained in the EPP spec,
fundamentally err by reference to a built-in derived type, or to
a primitive type?

Thanks in advance,
Eric