Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 13 Feb 2003 14:42:29 -0500

> > - in other environments, it might be OK for the data owner 
> to say "this is
> > what I will allow you as server operator to do with the 
> data I share with
> > you".  I thought some of the European contributors have 
> said this sort of
> > functionality is required under recent European privacy 
> laws.  This is
> > something we don't currently have in the protocol.
> 
> Disagree. The <dcp> states the purpose, recipients, 
> access-right (of the data
> owner), and retention period, of the policed session in which 
> some data will
> conditionally flow. For a server to offer <dcp1> ... <dcpN>, 
> it need only
> cycle these through a fairly small value-space to find the 
> least-restrictive
> policy to which the client (and presumably the registrant) 
> are willing to
> accept. APPEL attempts this, and the P3P WG attempted, and 
> abandoned for 1.0,
> a negociation or owner-preference signaling mechanism.

Remembering our original discussions of your data collection policy proposal
I know you disagree ;-).  What I'm trying to understand is why some
implementers and others (including, apparently, the IESG) don't agree that
it's sufficient.  What's driving the perceived need for a client-delivered
"do not publish" notification?  Is the spec not clear enough, or is the
mechanism inadequate?

> > I'm not sure that this is a "pick one or the other" situation,
> 
> Disagree. See above. Manditory beats optional (IESG's point), 
> regardless of
> utility.

Well, I agree with that -- the IESG is saying they want to see some sort of
"mandatory to implement" functionality.  Should we be trying to convince the
IESG that the DCP features address their concerns, or do we need to add
something else?

-Scott-

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 13 Feb 2003 15:18:56 -0500

> I know you disagree ;-). 

On selection:

	Assume N instances of the server, each offering a distinct
	<dcp> value, or one, cycling through a set of N distinct
	<dcp> values, or N distinct registries, each offering a single
	distinct <dcp> value.

On agency (who selects):

	EPP defines exchanges between registrars and registries, so
	"data owner" (originator) is not a direct actor.

>                        ...  What I'm trying to understand is why some

The <dcp> mechanism is optional. That might be the burr under some blankets.
Flip that bit and test again.

> IESG that the DCP features address their concerns, or do we need to add

OK. Lets talk about making the <dcp> M2I, and either leaving it at session
scope, and see if anyone can live with it.

Eric

---

From: Edward Lewis <[email-masked]>
Date: Tue, 18 Feb 2003 11:12:58 +0800

>IESG that the DCP features address their concerns, or do we need to add

Funny you should mention the latter.  Here are some snippets of a 
mail exchange I had with a member of the IESG:

>"Section 8.4 of RFC 3375. See the MUST part of [1]"

Paraphrasing the context of that: the IESG feels that the EPP spec 
does not meet this requirement.

I replied:

>But I bet a lot will feel that this passage from the base spec:
>
># "- An OPTIONAL <dcp> (data collection policy) element that contains
>#    child elements used to describe the server's policy for data
>#    collection and management."
>
>shows that we've already met the requirement.

And got this reply:

>Then the exact syntax etc for this DCP element MUST be described and included,
>because another requirement is that the protocol must be able to work without
>human intervention (I think the word used is "automatic").

My response:

>If you want a better definition of the dcp, that can be brought to the group.
>Looking through the base spec, the dcp is discussed, I assume the IESG feels
>that it is not presented well enough.

No further happened on the exchange.

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

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 18 Feb 2003 08:15:40 -0500

...
>human intervention (I think the word used is "automatic").

There's a schema.

...
> No further happened on the exchange.

I thought they were going down a substantive path, such as changing
the <dcp> implementation requirement from optional to manditory, or
a manditory pervasive (or scoped) leaf attribute, or ... or just
buggering off until they had something technical to contribute.

Aside #1.
Wearing my I'm-a-registrar-and-I'm-OK hat, I posted a note to to the
registrars constituency mailing list on our present quandry. Nothing
yet from the gTLD registrar business|requirements parties, so all of
this may be a non-issue. The RC will be meeting at the end of this
week, if enough Swiss dogs can be found to get us through the snows
of Washington and policy requirements for operation in the EU is on
the agenda.

Aside #2.
The geo-blah WG's docs (spam has local context, aluminum-hats and its
converse, advertizing, still have mind-share) focus on the preferences
of data originators, and not on the policies of data collectors. The
addition of a half-room of a mixed bag of groan-bots and greed-bots,
who are originator-aware (trans: registrant-aware), transport-unaware
(trans: reseller/registrar/registry-unaware), won't improve the work
attempted at the face-to-face.

What happened to our WG-only interim via-voca? If it fell victim to
duct-tape madness in the Beltway, it is time to give it oxygen.

Eric

---

From: Rick Wesson <[email-masked]>
Date: Tue, 18 Feb 2003 09:45:12 -0800 (PST)

Ed,

from this point further I request all corrispondance with the IESG be
cc'ed to this list. This issue has dragged on in part because of
gatekeeping by the chairs.

If the IESG wants to stir the pot they need to include us in the
converstaion.

I hope this is the last time I will request this as standard opperating
procedure.

best,

-rick

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 18 Feb 2003 16:09:06 -0500

Is it the co-chairs or is it us?

Digression. From -47 through -49 I worked for Engage, a company that had
some value proposition associated with http cookies, the results of this
were contributions to draft-jaye-http-state-mgt-nn.txt, contributions to
the W3C's P3P spec (in particular, the mechanism and semantic scope from
-jaye- to cookies), and the Customer Profile Exchange (CPex) trade body
standard for onward transport of customer profiles (wicked close to what
EPP is all about, minus the ICANN psychoactive drugs), to cookie handling
done in IE 5.5 et seq, and to draft-ietf-http-state-man-mec (rfc2965).

So, I had a modest exposure to a particular problem domain, and had some
reason to think that http's state management mechanism provided a mechanism
for sophisticated 3rd-party involvement in the http client-server model,
not entirely limited to Satan Worship, animal sacrifice, popups or banner
ads.

I mentioned at the Plenary in Pittsburg (-48) that the IESG's note on the
subject (draft-iesg-http-cookies-nn.txt) was in need of some contribution
from people with subject matter expertise. [People who's 9-5 was cookies,
demographics, profiling, and of course, Devil Worship.] From the podium,
Fred Baker was quick to agree that not all clue resided on his side of the
table. Yeah Fred! The next day I went in search of the authors, both the
Apps Area ADs (then). One blew me off, with attitude. The other informed
me that he knew more than I did, and the majority (of some group) was on
his side. This latter exchange happened with John Klensin as an onlooker,
which is one reason why John and I are friends, though we disagree on the
polarity of gravity.

So, draft-iesg-http-cookies-nn.txt became bcp44 and rfc2964, without any
further distractions to its authors. There is a quote from the back of
Mike Padlipsky's "Elements" that is appropos:

	Just because you are Constitutionally entitled
	to a personal opinion
	doesn't mean you're constitutionally entitiled
	to a professional opinion.

So, here we are, presumably possessed of at least enough clue to start a
fire using only damp bits of XML, stopped dead in our tracks for about a
half-year, by stuff that appears to be fairly aged roadkill.

Is it (a) the co-chairs' fault (and I've issues there, which are neither
here nor there), or is it (b) our fault?

I'm inclined to (b). 2026, in particular section 6.5.4, provides an appeal
procedure. If the working group fails to get either (a) adequate progress,
or (b) grounds to advance an appeal under section 6.5.4 of 2026, then the
working group is technically done, and has exhausted the process mechanisms
it has consensus to exploit.

The idea that the IESG can function like line-noise is sort of endearing.

Eric

---

From: Edward Lewis <[email-masked]>
Date: Fri, 28 Feb 2003 15:43:47 -0500

I don't know that there's a proper response to this request. 
Generally, I answer privately to private mail, publicly to public 
mail.  If anyone contacts me privately, I don't differentiate based 
on IESG membership status.

I use my judgement when it comes to deciding whether a conversation 
is better served on the public list.  The below referenced discussion 
didn't yield ( or hasn't yet yielded) anything that would add to the 
WG.

---

From: Rick Wesson <[email-masked]>
Date: Fri, 28 Feb 2003 14:52:29 -0800 (PST)

Ed,

The private discussion the wg chairs have had with the IESG have prevented
this group from moving forward; therefore I request all communication
between the IESG and the wg chairs also CC the list.

We have experenced 4 month delay because of this situation and it is
unacceptable. We still are in a state of limbo.

ed, please restate the issues, proposed solutions, wg consensus (if any
appears evident) and iesg issues in a single concise e-mail to this wg
so we can at the very least understand where we are in this process, and
how we can move it forward.

thanks,

-rick

---

From: Andrew Newton <[email-masked]>
Date: Fri, 28 Feb 2003 18:25:43 -0500

> between the IESG and the wg chairs also CC the list.

I don't know how you know the private discussions have prevented this 
WG from moving forward, but I'm guessing that it is not true.  PROVREG 
should use the same procedures used by all IETF working groups.  And if 
they aren't working out, then perhaps it should be addressed in a 
broader manner.  Perhaps this would be good input for the problem 
statement work currently in motion.

> unacceptable. We still are in a state of limbo.

I agree.  Lack of forward motion is frustrating.

> how we can move it forward.
This sounds like a good idea.

-andy