Subject: Re: [ietf-provreg] [BH] P3P and Extensible Provisioning Protocol

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 07 Apr 2003 20:27:41 -0400

Joseph,

> > It's not so much that HTTP was rejected, no one suggested doing it.
> 
> Understood.

There is an implementation.

> ACCESS

The vocabulary element(s) in the EPP schema which correspond to the ACCESS
element are not identical to those in the P3P schema.

p3p:nonident - does not collect identified data
epp:null - data is not persistent

The problem-domains are not identical. P3P is concerned with "initial data
collection", EPP is concerned with "onward transport" of data previously 
collected.

Comment: Data that moves from one onward-transport node to another may not
be persistent on any particular node. In particular, a registry could sink
part of a data flow (technical data) and discard part of a data flow (social
data).

> DISPUTES
> EPP doesn't support how a dispute can be addressed.

There is no vocabulary element(s) in the EPP schema which correspond to
the DISPUTES-GROUP element, and its child DISPUTES elements.

No requirement in the problem-domain exists.

Comment: There is a regulatory regime that is controlling for a class of
operators, hence of implementors. There is the complement to that class,
which lacks an equivalent single regulatory regime, and may be particular
to each element in that class (ccTLD operators). There is yet another class
for which little activity is present (non-tld operators, non-dns operators,
and non-IANA root dns operatos, if any).

> REMEDIES
> EPP doesn't support this, see question in DISPUTES.

See above.

> NON-IDENTIFIABLE
> EPP doesn't support this, not sure why.

The problem-domains are not identical.

> PURPOSE
> EPP supports p3p:{admin, contact, other} and epp:prov. I can see the PURPOSE 
> varying widely across application contexts and I think it makes sense to 
> drop and extend from this axes as appropriate.

The comment is not clear.

> REQUIRED

(N.B. An optional child element of PURPOSE. EBW)

1. No requirement in the problem-domain exists for users.
2. No requirement statement for data in the problem-domain is optional.

> RETENTION
> See ACCESS.

See above.

I hope this has helped.

Now for something ... individual.

I advocated the <dcp> construct for this problem domain, because I thought
it the best mechanism to policy the data, and to allow scoped policies.
I've tried to kill whois:43 by several means, stealth, poision, very blunt
instruments (my wit), etc.

Others reject the notion that a protocol with a fixed grammer targeting a
particular application domain, in particular data collection, is of the
slightest use in this problem domain, and insist upon mechanism(s) that
support registrant ("user" in p3p usage) defined access et al models.

As "others" are the IESG, looking at what bits of a data collection vocab
are substantially similar, or dissimilar, across problem domains, may not
be the best use of anyone's time.

I hope this has helped too.

Eric

P.S. It might help to keep things in focus to recall every now and again
just how much, or little, anyone actually pays for "privacy". Indirect
cost recovery models for the internet may be ... historic.

---

From: Joseph Reagle <[email-masked]>
Date: Wed, 9 Apr 2003 17:09:13 -0400

On Monday 07 April 2003 20:27, Eric Brunner-Williams in Portland Maine 
wrote:
> The problem-domains are not identical. P3P is concerned with "initial
> data collection", EPP is concerned with "onward transport" of data
> previously collected.

If the initial data collection had a particular policy (P3P) wouldn't it be 
best to pass on the initial P3P agreed to, with the data, when it is 
distributed to those with the "same" policies?

Let me back way up and ask what data is involved here? Was there a usage 
scenario? (Didn't see one, but I expect its clear to those involved with 
provreg, of which I'm mostly ignorant.) I was presuming, as you said, that 
the data was initially collected by a registrar and then shared with a 
registry. So for instance:
  https://www.gandi.net/whois?l=EN&domain=w3.org
contains personally identifiable data. My (continued) presumption was that 
the registrar, Gandi, might have a policy associated with the collection of 
this information. Now, Gandi might also share this with a .org TLD registry 
data base. So in it's initial <create> it would see the registry <greeting> 
and note its <dcp> (policy). If this didn't match the data it collected it 
under, then it might not upload the information if it said p3p:same, or it 
might if it said p3p:other-recipient. (In the first case, it's more likely 
to say p3p:public since whois is public, or at least to set its privacy 
policy based on the policies it knows it must interact with on the back 
end.)

However, my scenario, which is probably incorrect, fails to predict the 
variances in EPP.

> be the best use of anyone's time.

I didn't follow this bit.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 10 Apr 2003 12:33:04 -0400

>There is an implementation.

Sheesh, okay EBW, "no one suggested doing it - on our mailing list." ;) ;)

(I'm joking.  But, really, the implementation is news to me - it 
hasn't been mentioned in the group.)

As for the answer to most of the other points, the reason why you 
(now = Joesph Reagle) might not be seeing the expected detail is that 
we as a group are at a loss in defining what privacy means to us.

Given the scope of what we are accomplishing, a full determination of 
privacy is considered to be too much work within our venue.  We are 
settling on some mechanisms that we can only hope (at this time) will 
support a sufficiently large realm of interested parties.

I mention this because you ask about disputes, remedies, etc.  Those 
are things definitely beyond what we can afford to consider in our 
problem space.

PS - I should add that although a deeper discussion of privacy is 
somewhat beyond our (= IETF provreg WG) hopes given time and 
resources, questions on the topic are within scope.  It just might 
take some time to answer them.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

   ...as rare as a fire at a sushi bar...

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 10 Apr 2003 16:33:44 -0400

> Sheesh, okay EBW, "no one suggested doing it - on our mailing list." ;) ;)

Granted, I had prior general knowledge, but it did leak into PROVREG, via its
principle implementor.

------- Forwarded Messages

Delivery-Date: Sat Feb  1 13:37:27 2003
Date: Sat, 1 Feb 2003 19:19:13 +0100
From: Otmar Lendl <[email-masked]>
To: [email-masked]
Subject: [ietf-provreg] FYI: nic.at presentations from RIPE44
Sender: [email-masked]

On 2003/02/01 18:02, Jaap Akkerhuis <[email-masked]> wrote:
> At the DNR-forum at RIPE-44 last week, the polish registry presented
> their implementation of EPP.

On a related note: Our presentation from monday's Centr workshop
are online as well. You can get the .ppt files (and the latest source
code tarballs) from 
http://sourceforge.net/project/showfiles.php?group_id=66464 .

/ol

------- Message 2

Delivery-Date: Sat Feb  1 14:03:03 2003
To: [email-masked]
Subject: Re: [ietf-provreg] FYI: nic.at presentations from RIPE44 
Date: Sat, 01 Feb 2003 19:51:52 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    On 2003/02/01 18:02, Jaap Akkerhuis <[email-masked]> wrote:
    > At the DNR-forum at RIPE-44 last week, the polish registry presented
    > their implementation of EPP.

    On a related note: Our presentation from monday's Centr workshop
    are online as well. You can get the .ppt files (and the latest
    source code tarballs) from
    http://sourceforge.net/project/showfiles.php?group_id=66464 .

Let me clarify a bit about this. At the first day of RIPE meetings
there is usually a CENTR technical meeting. This time, the afternoon
was devoted to EPP.  SInce the meeting is limited to CENTR members
and invitees (Scott Hollenbeck was there, among others) I don't
feel comfortable about quoting from that, although often the meeting
minutes are published on the CENTR website.

Anyway, Otmar Lendl on behalf of the Austrian registry, presented
at the centr-tech meeting an implementation of an EPP server as a
mod_epp Apache module.  It is nice to see that this is actually
public information. For details, see the URL he mentions.

	jaap

------- End of Forwarded Messages

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 11 Apr 2003 06:20:59 -0400

> If the initial data collection had a particular policy (P3P)

This may be a theory-of-foo bump, or it may be a slow moving armidillo, but
data originates at a registrar.

We (epp-hat==1) aren't designing the registrar's UI.

> ... wouldn't it be 
> best to pass on the initial P3P agreed to, with the data, when ...

This is an aside, but (you asked for it). A party interposes on the data
flow between source and sink, and edits the data. Is policy unaffected by
the transform? I gave this a lot of thought before, and after, the joint
WAPF/W3C meeting in Munich (Dec 1999), and concluded that proof of closure
was not trivial.

For the IETFers, take a look at any of the three cache BoF/WGs that came
out two years ago -- there was a reason why Mark Nottingham (co-chair, WEBI)
attended our f2f at IETF-51 (London), and it wasn't just because we were
then both contributors to the W3C's P3P Spec WG.

Of these, only Leslie's considered the possibility that cached content
was policied (in an IRTF-IDRM-esque fashion) before it was transformed
for edge device delivery.

For the P3Pers, consider a nice bit of html with a nice p3p statement in
the usual WKL. It is accessed via a WAP device, and transformed by some
WAP content management cache for "last mile" lower bandwidth link reasons,
and additional operator policy goals ("walled garden"). How does an user's
p3p evaluation engine evaluate the delivered p3p statement(s)?

Anyway, we don't know that there was a p3p statement when the data was
initially collected by the agent/reseller/registrar. What we do know is
that a registrar is surrendering, and possibly retaining, data, and a
registry is collecting, and possibly discarding, data.

> when it is distributed to those with the "same" policies?

But it isn't. There are several adminstrative or jurisdictional policies
that the registrar-collected data might be provisioned (onward-transported)
to, and the registries may be unable, under the distinct operational and/or
policy regimes they operate under, to accept some registrar-collected data,
regardless of the policy under which that data was collected.

...

> I didn't follow this bit.

Assume no one has any use for 95/46/ec, or the OECD Guidelines, or the FTC
rule-of-the-day (generally, policy on collectors), and only wants raw read
and write access on the registries, and a trap on read-requests by other,
to interpose a write (or its static equivalent, some sort of mask), for a
registrant (user), and/or his/her cluefull agency.

Now (epp-hat==1) and (p3p-hat==1) are very, very far apart. Sailing on
different currents altogether, and diverging too.

Fortunately, this [1] shows that the problem is minor. Also, the ICANN
Registrars may be limiting whois (both bulk and :43) more effectively
than we (PROVREG +/- IESG) are.

Cheers,
Eric

[1] http://www.cdt.org/speech/spam/030319spamreport.pdf

---

From: Joseph Reagle <[email-masked]>
Date: Mon, 14 Apr 2003 17:34:47 -0400

On Friday 11 April 2003 06:20, Eric Brunner-Williams in Portland Maine 
wrote:
> This may be a theory-of-foo bump, or it may be a slow moving armidillo,
> but data originates at a registrar.

So is the information covered is not my data (my contact info I've placed 
with the registrar) but the registrars information? I continue to fail to 
understand exactly what information the practice applies to and governs. I 
suspect a step-by-step scenario would be immensely useful.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 14 Apr 2003 18:11:53 -0400

> suspect a step-by-step scenario would be immensely useful.

We have some rules, things like delete-object-before-create-object returns
an error.

What we don't have rule about are where registrars go to get "data", they
could just be making it up.

There is no in-band mechanism to distinguish "registrar-generated-data"
from "entity-other-than-registrar-generated-data".

There is a data collection policy announcement from a data collector, which
is indifferent as to the originator of the data which it collects, and it is
possible that a registrar might use non-fictive data.

Did the registrar use P3P when collecting the data? I've no idea. I don't
even know if the registrar was the initial data collector, or if the initial
data collector was a reseller and the registrar engaged in onward-transport.
I don't know how the data got to the registrar.

What the <dcp> covers is _everything_ in a session. Since sessions exhaust,
for the time being, the semantics of state exchange between registrars and
registries, everything collected by a registry is policied. Note that any
registry may have a number other than one of applicable <dcp> statements,
with non-overlapping session-scope.

Eric

---

From: "Ross Wm. Rader" <[email-masked]>
Date: Tue, 15 Apr 2003 10:51:54 -0400

> There is no in-band mechanism to distinguish 
> "registrar-generated-data" from 
> "entity-other-than-registrar-generated-data".
<snip>
> I don't even know if the registrar was the initial data 
> collector, or if the initial data collector was a reseller 
> and the registrar engaged in onward-transport. I don't know 
> how the data got to the registrar.

Perhaps this is overkill, but I can't underscore enough how "right" Eric
is with this observation - it is not uncommon that the chain looks like:

Registrant -> affiliate partner -> reseller -> reseller -> registrar ->
registry...

This is even more predominant in environments like .cn where every
non-domestic registrar is actually a reseller of Neulevel's.

The point that needs to be underscored is that, as Eric pointed out,
each link in the chain has the opportunity to add or change data to the
transaction as they see fit - and experience shows that it happens on a
regular basis.

                       -rwr

"There's a fine line between fishing and standing on the shore like an
idiot."
- Steven Wright

Get Blog... http://www.byte.org/