Subject: [ietf-provreg] where are we with privacy

From: Edward Lewis <[email-masked]>
Date: Sun, 19 Jan 2003 21:00:15 -0500

It's been about a week since we last spent time on privacy.

It seems to me that we've been asked to put in hooks into the base of 
the protocol to allow for a generic privacy policy to be stated. 
Here's why I think we haven't gotten anywhere:

1) Although having hooks is desirable in the abstract, there's no 
concrete understanding of why we should bother defining hooks.

2) Privacy is too undefined to know what "generic privacy" is.

3) We already have a potentially fine mechanism for tailoring privacy 
considerations in the extensions mechanism.

4) The proposed "doNotDisclose" mechanism seems to work with some 
environments, but the wording/name of it is a bit ambiguous.

5) We aren't willing to research the privacy topic within this WG.

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

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 23 Jan 2003 10:42:36 +0100

>considerations in the extensions mechanism.

The purpose of my message was exactly to give my opinion on these
three points: why there is the need to include mechanisms to specify
privacy level in the protocol, why they should be in the base protocol
rather than in extensions, and what a reasonable level of "generic
privacy" is.

Of course that was just my opinion, supported by my personal
experience. But it was an attempt to give you real life requirements
that the service should be able to support. You'll never be sure that
those requirements cover all possible needs for privacy specification,
but you can be sure that at least those ones are necessary for whoever
operates in Europe. (The EU law applies to any data processing
happening in the EU, so it applies both to EU registries and to EU
registrars.)

>environments, but the wording/name of it is a bit ambiguous.

Then let's find a better wording :-)

>5) We aren't willing to research the privacy topic within this WG.

But, IMHO, you can't write a good technical spec if you're not willing
to research and address all the related topics. I fear we can't pick
just the parts of the job we like.
-- 
vb.                  [Vittorio Bertola - vb [at] bertola.eu.org]<---
-------------------> http://bertola.eu.org/ <-----------------------

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 23 Jan 2003 07:15:40 -0500

I don't disagree that the <dcp> should be in the base, however, the consensus
by the contributors at the time on the question was that the <dcp> should be
an extension.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 23 Jan 2003 11:06:16 -0500

>happening in the EU, so it applies both to EU registries and to EU

Your message was quite helpful.  I did just get around to reading it 
myself.  (I seem to habitually exhibit a 1 week delay.)  Your message 
put a more concrete spin on the problem to solve.

Not having access to an ICANN contract myself (nor much understanding 
nor patience for contract law), my understanding is that ICANN 
requires public distribution of (some/all) data from registries. 
ICANN has discussed data escrow to backup failed elements of the 
shared registry system, I don't know if that is required - and if 
that enters into privacy concerns.  ICANN requires the use of a 
standard protocol to make the shared registry system work (which is 
where we come in).

Does the situation above mean that there may be a conflict between 
European privacy law and the contracts for the gTLDs?

>Then let's find a better wording :-)

That's certainly one approach.  In a private email to someone else I 
suggested as much, i.e., I agree with you.

>just the parts of the job we like.

This isn't a matter of whether or not we want to tackle a particular 
work item but a reflection on the scope of the IETF work.  The IETF 
is positioned to solve concrete problems.  The structure of the IETF 
leads it to behave poorly when the problem is abstract, lacking a 
good measure of success to identify when the problem is solved.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 23 Jan 2003 16:06:05 -0500

w.r.t. point 5

We've considered ...

bilateral (out of band) contract, between registries and registrars, [SH].
hop-by-hop (in band) announcement, between registries, registrars,
(and implicitly resellers) [EBW].

We haven't considered ...

end-to-end (in band) requirement, between users and registries [JS, and IESG,
cheritably construed],
end-to-end (in band) requirement, ditto, with per-hop binding [JS, and IESG,
cheritably construed].

If we're to research anything, it isn't "privacy", it is which AAA model is a
better fit.

We started without users, and resellers were just registrar-bloblets, and for
many only CNO (not Cherokee Nation of Oklahoma) "mattered". Those were the
consensus points of this mailing list.

There is this proto-blob of gunk that arises out of an resource allocation request.
In route to the allocator, zero or more intermediaries read, and possibly write,
bits of the proto-blob.

In EPP, the syntatic form of the proto-blob is XML, and the resource is a domain
name.

Before we ask what is in the proto-blob, let alone what it signifies, we need to
be in agreement who its writers and readers are.

If "users" are amongst the writer-set, yet we retain the authentication model we
have (only registrars and registries are authenticable), and the effect of these
"users" acting as writers on an additional attribute of each element in the schema,
we've got what looks like line noise, pre-flipping bits at random, outside of the
agency of the authenticated (rrar, rtry) set.

Adding users as writers is a change. We can pretend they are simply line noise
and not change our model. When we account for the parties, and the transactions
between the parties, then we can solve for what thing that isn't AAA the parties
are exchanging.

No "research" into what "privacy" means, please. The P3P spec group, and the old
IRTF activity, did the best they could, without ICANN modifying the value of the
work product.

Eric
(not wearing my tattered P3P Spec Group I.E. hat, just the usual asses ears)