Subject: Re: privacy

From: Rick Wesson <[email-masked]>
Date: Wed, 8 Jan 2003 08:29:29 -0800 (PST)

Randy,

> > I have some thoughts on this. I prefered the capability in scott's second
> > to the last proposal [1] -- I also have an issue with the IESG deciding
> > what in the most appropiate methodology.
>
> the iesg members specifically said we did not want to decide the method,
> though some decades of programming practice does suggest one.  what we
> do care is that there is a mechanism which may be invoked by policy.

would you please discuss your rationale in the light that all gTLD
registrations will also be published in the whois negating any utility of
your requirement.

furthermore, since gTLD registries and registrars (the primary users of
this work product) are required by contract to publicly publish this
information, the paries using this privacy enhanced protocol would be
exposed to a serious liability concern as registrants expect information to
be private but contracts require it be published.

IMHO, privacy needs to be addressed in a superset of the protocols (epp,
crisp, whois) and a specific group tasked with that job; requesting
prov-reg to preform this task appears to be short sighted knee-jerk
reaction.

I'd appreciate it if you either enlighten us with more detail or
politely back off.

-rick

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 8 Jan 2003 17:50:17 +0100

On Wed, Jan 08, 2003 at 08:29:29AM -0800,
 Rick Wesson <[email-masked]> wrote 
 a message of 32 lines which said:

> crisp, whois) and a specific group tasked with that job; 

This is very reasonable (sorry for the fine members of the Provreg
group but last-minute attempts to solve a problem as large as the
privacy policies in a few lines of patch to the I-D are quite
laughable).

But such a group already exists: W3C's P3P group. P3P can be used for
more than Web sites and they are willing to do what it needs to extend
their framework to registry privacy policies.

---

From: Andrew Newton <[email-masked]>
Date: Wed, 08 Jan 2003 12:32:56 -0500

> be private but contracts require it be published.

I hope that this body of work would also be applicable to ccTLD's as 
well, if they so desire to use it.  In addition, I thought the intent of 
the "E" word in "EPP" was for things beyond domain names.  Given this 
and the requirement for the mechanism to be "invoked by policy", I don't 
see why it should be manditory to implement.

> prov-reg to preform this task appears to be short sighted knee-jerk

If the scope of this would be for domain names, it does seem that there 
should be some effort to make sure everybody is on the same page.  A 
scope larger than domain names would be a rathole.

-andy

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Jan 2003 13:49:45 -0500

Although your message might sound derogatory (referring to "quite 
laughable") I think your sentiment is accurate and understood.  I 
think the enormity of the issue is why the group has yet to be able 
to form a consensus.  That point has been made.

During the Atlanta meeting we did talk about P3P and it's 
applicability to us.  (It's mentioned in the meeting minutes.  (See 
action item #3 and a discussion later in the minutes, oh, BTW - 
Rick?;) )

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Rick Wesson <[email-masked]>
Date: Wed, 8 Jan 2003 12:58:50 -0800 (PST)

> nope.  to repeat yet again.  we are not discussing privacy *policy*.
> we are discussing a mechanism by which a wide set of policies may
> be implemented.  operating system theory 101.

maybe we had different instructors... to discuss capabilities of
implementing a policy we must understand the range of policies and that is
clearly out of scope for this group.

I took shop class too, where we learned about square pegs, round holes
and hammers, none of which is of any benefit here.

best,

-rick

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Jan 2003 16:08:53 -0500

At 12:40 -0800 1/8/03, Randy Bush wrote:
>>  Excellent point, I could not agree more ... IMHO all of this goes to the
>>  much larger issue of privacy policy across all IETF protocols
>

What is frustrating to me is that EPP already has a mechanism as you 
describe - the extensions.

Obviously you are asking for something more specific - something that 
is required in the implementation that is more specific than the dcp 
element in the base.

I have this question.  Given the choice between making something an 
optional part of the base protocol or making it an extension to the 
base, what criteria would you follow in making the decision.  A 
couple of weeks ago the following message laid out some criteria for 
another topic:

http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00036.html

---

From: Randy Bush <[email-masked]>
Date: Wed, 08 Jan 2003 09:23:03 -0800

> would you please discuss your rationale in the light that all
> gTLD registrations will also be published in the whois negating
> any utility of your requirement.

one - they won't be, as some registrants register from legal
juristictions which have stronger privacy requirements.  please
listen to what paf is trying to tell you.

two - i know this will come as a shock, but there are registries
other than gtlds

three - there are more concerned parties here than registries.
again, listen to paf

randy

---

From: Richard Shockey <[email-masked]>
Date: Wed, 08 Jan 2003 12:52:31 -0500

Excellent point,  I could not agree more ... IMHO all of this goes to the 
much larger issue of privacy policy across all IETF protocols and that is 
something that is clearly outside the scope of PROVREG.

IMHO  the IESG should withdraw the privacy requirement for EPP and allow 
the existing documents to go forward to PS until such time as the IETF 
community can get some clear architectural direction and consensus on where 
we want go.

Frankly all of the proposed solutions to the privacy requirement have a 
strong smell of duct tape, bailing wire and used chewing gum. Yes these 
things can work but its not a particularly good archichecture in the long term

Some of you may remember that I stood up at the plenary in Atlanta and 
asked the IESG specifically about where IETF is going with privacy issues 
and I believe it was Steve Bellovin who mentioned that there was ongoing 
work in this area but it was not ready yet.

Well I submit its time ..or at the very least I would suggest that there is 
consensus for a BOF in SF on "Where is the IETF going with Privacy issues?"

>their framework to registry privacy policies.

well that said I'm not sure about timetables... I've personally attended 
the workshop that W3C had on the future of P3P and given the time it took 
to get the highly limited and constrained P3P 1.0 out I don't hold out much 
hope they can be relied on here if timing is a issue. You can all read 
their final report ..

##########

From: Daniel Weitzner <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Cc: "w3c-P3P-specification@w3. Org" <[email-masked]>,
    [email-masked]
Subject: P3P Workshop report now available
Date: Mon, 6 Jan 2003 20:58:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:[email-masked]?subject=unsubscribe>
Content-Type: text/plain;
         charset="iso-8859-1"

Dear colleagues,

I'm happy to announce that the summary report on the Future of P3P Workshop
is now available at:

         http://www.w3.org/2002/12/18-p3p-workshop-report.html

On behalf of Lorrie & myself, thanks to all of you for your thoughtful
participation and for preparing the action plans for future work. Those
plans are now all linked from the end of the workshop report. The P3P
Coordination Group will be looking in detail those and propose to this
mailing list draft charter(s) for future P3P work. Any new work will
ultimately have to be review by the W3C Advisory Committee, but I believe
that we should use this mailing list of workshop participants to develop the
proposals together.

The workshop report is publicly accessible so feel free to pass along the
URL to others who may be interested.

Best for a Happy New Year,

Danny Weitzner

--
Daniel J. Weitzner                              +1.617.253.8036 (MIT)
World Wide Web Consortium                       +1.202.364.4750 (DC)
Technology & Society Domain Leader              <[email-masked]>
http://www.w3.org/People/Weitzner.html

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto:[email-masked]> or <mailto:[email-masked]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: "Paul M. Kane" <[email-masked]>
Date: Thu, 09 Jan 2003 09:10:36 +0000

Well said Randy.......

IMHO the spec should contain the basic parameters then each registry can 
  extend to accomodate the applicable policy (_laws_of_the_jurisdiction) 
..... which probably means that Registars, if they want to trade in the 
jurisdiciton will have to adjust their interfaces (C2Rr and Rr2Ry) 
accordingly.
The effect will be that gTLD Registries (as ccTLD registries have to do 
already) must respect national operating conditions if they want 
customers from that nation.... but such is politics not technology

Best

Paul

---

From: Randy Bush <[email-masked]>
Date: Wed, 08 Jan 2003 13:15:22 -0800

> implementing a policy we must understand the range of policies
> and that is clearly out of scope for this group.

which is one of the reason per-field granularity is desired.  it
maximizes flexibility, i.e., you're not just stuck with "don't
publish tech poc."  it handles the union of requests heard from
various registrars, locales, and registries.

> I took shop class too, where we learned about square pegs, round
> holes and hammers, none of which is of any benefit here.

then why mention them?  can we reduce the slanging match and stick
to engineering and computer science?

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 08 Jan 2003 12:40:56 -0800

randy

---

From: Eva Stengård <[email-masked]>
Date: Thu, 9 Jan 2003 13:06:26 +0100 (CET)

I can only agree to this. If it is of any help I wrote a message to the 
CRISP group some time ago that included a translation (my own, apologies 
for the quality) of those parts in the Swedish implementation of the 
European Data Protection Act that I felt was relevant in the context of 
domain name business.

Because the Act includes restrictions applicable at export of data, such 
as a transfer of data between registrar - registry on different sides of 
the EU border, the protocol used must be able to carry information, 
collected by the sender, that impose restrictions on how the recipient may 
use the data.

For those of you interested, my message can be found at:
http://lists.verisignlabs.com/pipermail/ietf-not43/2002-April/000079.html

Hope this can be of some help,

-- 
Eva Stengård
Project Associate
MuseDoma
http://musedoma.museum/

---

From: Randy Bush <[email-masked]>
Date: Thu, 09 Jan 2003 03:43:20 -0800

> customers from that nation.... but such is politics not technology

in idle moments, i am trying to understand the mechanisms and
poilicy useful/needed by a swedish registrant, using a registrar
located in brasil, to register in a domain which has its registry
in say american or new zealand juristiction.  and, of course, the
registrant has personal preferences, "don't publish my fax number."

randy

---

From: Joe Abley <[email-masked]>
Date: Thu, 9 Jan 2003 07:32:41 -0500

> registrant has personal preferences, "don't publish my fax number."

Does it seem that a simple, boolean "do not disclose" flag on each 
field is sufficient to accommodate the privacy requirements of that 
scenario?

Or is there a chance that data might be disclosable to different 
parties in different ways, based (for example) on geography or legal 
jurisdiction?

If there is no chance of that, then the dnd attribute proposal might be 
a fine framework to put in place. The question does not seem a 
naturally trivial one, however, since it encompasses all existing (and 
all future) privacy policy in every jurisdiction that might now (or 
ever) be home to a person with internet access.

Joe

---

From: Randy Bush <[email-masked]>
Date: Thu, 09 Jan 2003 04:38:08 -0800

> field is sufficient to accommodate the privacy requirements of that 

one can always imagine more complex scenarios.  but the
per-attribute dnp approach seems to be one of those which covers
the important cases, certainly the current ones, with a simple
mechanism.  it's like one of those 90% solutions with 10% of the
cost.

but if you have a real, current, useful, and needed case it does
not cover, now would certainly be a good time to describe it.

randy

---

From: Karl Auerbach <[email-masked]>
Date: Thu, 9 Jan 2003 10:46:57 -0800 (PST)

On Wed, 8 Jan 2003, Randy Bush wrote:

> maximizes flexibility, i.e., you're not just stuck with "don't publish
> tech poc."  it handles the union of requests heard from various
> registrars, locales, and registries.

I'm not sure that mere item tagging is adequate.

Way back in the 1970's in the days when we were worrying about database
privacy rather than net privacy it was realized that data has a
synergistic property - that N items of sensitive S often have an aggregate
sensitivity much larger than N*S.

Thus the privacy policies had to express limitions of combinations.

Sometime the policies had to express other things, such as whether to lose
precision (e.g. turn a full postal address into a mere postal code, or a
phone number into a mere city code) possibly based on relationships 
between the requestor and the requested record (e.g. obtain records only 
when subject's salary is lower than that of querier.)

I don't think that these kinds of policies can be mechanized with only
simple item tags.  Certainly tags are useful and valuable for simple
scenerios.  And it may be that they are a good balance between nothing and
a fully flexible generalized system of enormous complexity.  But until 
somebody actually thinks through the generalized systems it's hard to know 
if simple tags are, in fact, a good middle ground or whether they will 
prove to be a good idea that doesn't quite do the job (like ICMP source 
quench) and were a waste of time to specify and to implement.

		--karl--

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 09 Jan 2003 14:57:07 -0500

> mechanism.  it's like one of those 90% solutions with 10% of the

I wrote on the subject earlier [1], I'm unaware if anyone read that
memo. No matter.

> not cover, now would certainly be a good time to describe it.

Assume the affirmative, that per-attribute dnp "works" for the case
of "publication".

	Q1. How long may the "do not publish" data be retained by
	    the data collector?
	Q2. How may the "do not publish" data be modified by its
	    author(s) during this retention period?
	Q3. To what purposes other than "do not publish" may the
	    "do not publish" data be put during this retention
	    period?
	Q4. Does "publication" and "do not publish" have a single,
	    unique, consistent meaning, either during the period
	    of retention of, or in all instances of some "do not
	    publish" data?
	Q5. How is any change to an aspect of the above made known
	    to the author(s) of the affected data?

A dnp value associated with a datum, e.g., an end-point identifier
associated with a domain name registrant, could be retained without
limit by a reseller, a registrar, and a registry-operator, and be
retained incorrectly (which may be a blessing), and re-purposed by
any data collector, and the purposing itself re-defined (possibly
transforming "not publish" into "publish"), without detection to a
party other than the collector(s), e.g., the original author(s).

Again, its a small matter.

Eric

[1] draft-brunner-epp-data-considerations-00.txt