Subject: RE: [ietf-provreg] our meeting slot in SF

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 28 Feb 2003 14:20:47 -0500

> THURSDAY, March 20, 2003
> 0900-1130 Morning Sessions
> APP     provreg   Provisioning Registry Protocol WG
> 
> 
> Time to send in agenda suggestions...there are some obvious ones, I 
> won't disallow anyone from suggesting the obvious. ;)

OK, then how about putting a slot in to get to the bottom of addressing the
IESG privacy comment -- assuming we can get the needed IESG members in the
room to get it settled.

-Scott-

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 28 Feb 2003 22:06:35 -0500

I second Scott's suggestion, though in the general sense that getting some
substantive response from the IESG is in theory better than not getting a
substantive response, as I won't attend the face-to-face meeting of some
of the working group. I don't personally care if a member of the current
IESG contributes in an individual capacity, or if the IESG sits en banc,
during the scheduled face-to-face, though I appreciate those who've worked
on this set of drafts over the past two years who are present at this
meeting have a keener interest in the time and place some eventual disclosure
is offered.
  
Eric

---

From: "Ram Mohan" <[email-masked]>
Date: Fri, 28 Feb 2003 22:47:21 -0500

amen

-ram
----- Original Message -----
From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>; <[email-masked]>
Sent: Friday, February 28, 2003 2:20 PM
Subject: RE: [ietf-provreg] our meeting slot in SF

> IESG privacy comment -- assuming we can get the needed IESG members in the

Date: Fri, 28 Feb 2003 14:52:29 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry
Sender: [email-masked]

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

On Fri, 28 Feb 2003, Edward Lewis wrote:

> 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.
>
> At 9:45 -0800 2/18/03, Rick Wesson wrote:
> >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
> >
> >
> >>  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:
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                          +1-703-227-9854
> ARIN Research Engineer
>

Date: Fri, 28 Feb 2003 15:43:47 -0500
To: Rick Wesson <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

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.

At 9:45 -0800 2/18/03, Rick Wesson wrote:
>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
>
>
>>  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:

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Subject: RE: [ietf-provreg] our meeting slot in SF
Date: Fri, 28 Feb 2003 14:20:47 -0500
Sender: [email-masked]

-Scott-

Date: Fri, 28 Feb 2003 13:35:11 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] our meeting slot in SF
Cc: [email-masked]
Sender: [email-masked]

THURSDAY, March 20, 2003

Time to send in agenda suggestions...there are some obvious ones, I 
won't disallow anyone from suggesting the obvious. ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: [ietf-provreg] Re: Fwd: 56th IETF WG/BOF Scheduling 
Date: Mon, 24 Feb 2003 11:14:23 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed,

Several people have asked me if I plan to attend -56.  I'm not.

I won't enter a TSA zone of control (e.g., US Airport) for any
reasons other than family emergency.

I passed through three TSA checkpoints on my travel to last week's
meeting of the Domain Registrar Constituency, held jointly with
several of the Domain Registries.

I was subjected to special processing at two of the three checkpoints.
The last time I flew PWD/NYC/WDC the same results obtained.

Everyone's tolerance for this sort of thing is their own. Mine
has simply been exceeded.

Eric

To: Rick Wesson <[email-masked]>
cc: Ram Mohan <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Sun, 23 Feb 2003 16:50:36 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Rick,

If rfc3375, sec. 8.4, [1], last sentance read:

   The protocol MUST provide services to identify registrant data
   publication policies.

Instead of:

   The protocol MUST provide services to identify data collection
   policies.

Then we'd share a common requirement statement.

A friendly suggestion: pop some <mumble> into a draft of 3375bis and
get it with some similarly inclined co-authors in before the -00 cut
date.

Then we could discuss if 3375 erred (and we all know the putative error
is mine).

With 3375bis creating a registrant participant in EPP, we can look to
the consequences, or if the scope of registrant-as-actor is limited to
<dnp> values.

Comment #1:

Regardless of the contents of a <dnd> container, it does not allow any
party to state the purpose, recipients, retention period, or access to
the publication data, only some binary property of "disclosure". What
does "disclose" mean?

Comment #2:

The <dcp> we've got has a finite set of elements, each taking attribute
values over a finite set, each with a mechanism to extend the set. I'll
use <glob> to discuss, without unnecessary overspecification, the value
space we're exploring, and who sets these values.

If a <glob> arises from some party other than an EPP client or server,
then it must take on values other than those defined between the EPP
nodes, otherwise it has no independent existance.

	Example: if registrant_A sets <glob> to <1, 2, 3<2,2>>,

		 and <glob> values of <0-I, 0-J, 0-K<0-L,0-M>>
		 are within the repitoire of the registrar/registry,

		 then there is no way of verifying that the registrar
		 didn't set the value of <glob> to a value in its
		 repitoire, in particular, <1, 2, 3<2,2>>.

So, the registrant only becomes "visible" when s/he goes off-reservation
and uses some portion of the value-space that is outside of the operational
practice of the registrar/registry, either because they subset the maximal
defined set of values, or because the registrant extends the maximal
defined set of values.

So, if the registrant creates a <glob> that is outside the space of values
either defined in some standard or operational practice, then the registrant
exists as an independent actor.

So, that's the first awkwardness. The registrant must utter something that
is a complete surprise to the registrar/registry, such as using "00" as a
value for the ccType element, or defining (an extended utility type) a cc5Type
with the length value 5, to allow codes outside of the 639:2 set of values,
e.g., change "US" to "BUSH2".

The second awkwardness is that for the registrant's access policy assertion
to be non-fictional, it has to be capable of binding the conduct of some
other actor, and for the conduct of that actor in varience of that policy
to be detectable.

So, to continue with the ccType example, the registrant would have to be
able to cause an <info> command response to be generated, and in particular,
determine if the contact:postalInfoType's child element either has
a value of "00" or type cc5Type.

Alternatively, for valid values (subsetted by the operational practice of
the registrar/registry), or valid extensions, valid values by the registrant
would result in protocol errors generated by either the EPP client or server.

So, what does a registrant bring to the party, and is it actually worth
having?

Suppose Randy wanted to no-disclosurer for his name as registrant of psg.

If the <dcp> exchange between Tucows and VGRS has
	<recipient><ours/></recipient>
what requirement hasn't been met?

If it is
	<recipient><ours/><public/></recipient>
then Tucows is free to error-out and fail the data propogation to VGRS.

If the <dnd> exchange between Randy and Tucows and VGRS has
	<dnd><contact:name></dnd>
and for reasons discussed above, the semantic of <dnd> is opaque to the
EPP entities, under what set of circumstances could Tucows error out and
fail the data propogation to VGRS? Only if VGRS generated an error? What
if VGRS had an accept-all or refuse-any for non-empty <dcp> elements?

Why do we even need Randy to be involved in this <dnd><contact:name></dnd>?
If Randy can't do anything surprising, then we can whittle his set of
choices down to {0,1}, without loss of generality.

I don't play a lawyer on the net, but there are reasons why 46/95/EC et
seq. has the exposure of the data collection policies of the data collector
as the object of its descriptive focus.

I believe in Satanism, mocking the IESG, depricating the brownie baking
skills of Laura Bush, and that "empowering the registrant" is significantly
harder than beliving in it.

Worst ;-)

Eric

Date: Sun, 23 Feb 2003 11:20:47 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Ram Mohan <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>, <[email-masked]>
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry
Sender: [email-masked]

Ram,

On Sat, 22 Feb 2003, Ram Mohan wrote:

> We're looking into a <dcp> required policy for the .info registry; For the
> .org registry, we're also trying to determine the appropriate technical
> measures that would make PIR's proposed "OrgCloak" data-protection service
> viable.
>
> A session-specific <dcp> mandatory approach is appealing.

I see how a registry might prefer the <dcp> proposal, however I believe
that the <DoNotDisclose> proposal, where a container allows the
client to set which elements should not be disclosed. Though its simular
to <dcp> It potentially allows the registrant to decide which elements to
protect.

<doNotDisclose>
    <contact:name>
</doNotDisclose>

Also <dcp> requires the policty to be set by the registry, and <dnd>
allows the policy to be set by the registrant.

I believe empowering the registrant is the direction we should take.

best

-rick

To: "Ram Mohan" <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, "Eric Brunner-Williams in Portland Maine" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Sun, 23 Feb 2003 13:56:41 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> We're looking into a <dcp> required policy for the .info registry; For the
> .org registry, we're also trying to determine the appropriate technical
> measures that would make PIR's proposed "OrgCloak" data-protection service
> viable.

Good. Let me know if you want my help.

>A session-specific <dcp> mandatory approach is appealing.

I'm glad you think so.

Eric

From: "Ram Mohan" <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, "Eric Brunner-Williams in Portland Maine" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry
Date: Sat, 22 Feb 2003 14:19:52 -0500
Organization: Afilias
Sender: [email-masked]

>If you're not publishing a data
>collection policy, is there any specific issue that's driving that
decision?

>I haven't decided what makes sense for the .com and .net registry yet, but
>other people who are using EPP in domain registry operations must have been
>through a decision process.  Come on, people, please let us know what
you're
>doing with respect to privacy and data collection and why you're doing it!
>We need some real data points to help close the discussion with the IESG.

We're looking into a <dcp> required policy for the .info registry; For the
.org registry, we're also trying to determine the appropriate technical
measures that would make PIR's proposed "OrgCloak" data-protection service
viable.

A session-specific <dcp> mandatory approach is appealing.

-ram
----- Original Message -----
From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>; "Eric Brunner-Williams in Portland
Maine" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 13, 2003 9:56 AM
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry

> > This is a good request.  This is one of the missing pieces of the
> > converstation.
> >
> > At 11:02 -0500 2/11/03, Eric Brunner-Williams in Portland Maine wrote:
> > >>  The WG should note that implementers of real-world
> > privacy policies are
> > >>  finding it necessary to add a "do not disclose" element.
> > >
> > >Could someone, possibly an implementor, comment on the
> > design choice that
> > >did not utilize the <dcp> element, and disclose its
> > deficiencies? I can
> > >guess, but it would be nice to hear from someone else who
> > considered it
> > >and found it failed to meet a requirement.
>
> Is Eric's request behind a thought that we are considering either the
> current DCP functionality, or the "do not disclose"-proposed
functionality,
> but not both?  I can easily see a need for both:
>
> - in some environments, it might be OK for the server operator to say
"this
> is what I will/might do with data, and if you as data originator give me
> data you are agreeing to my policy".  We have this in the protocol right
now
> with the <dcp> element.
>
> - 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.
>
> I'm not sure that this is a "pick one or the other" situation, but I'm
also
> interested in implementer perspectives.  If you're not publishing a data
> collection policy, is there any specific issue that's driving that
decision?
>
> I haven't decided what makes sense for the .com and .net registry yet, but
> other people who are using EPP in domain registry operations must have
been
> through a decision process.  Come on, people, please let us know what
you're
> doing with respect to privacy and data collection and why you're doing it!
> We need some real data points to help close the discussion with the IESG.
>
> -Scott-
>
>

To: Rick Wesson <[email-masked]>
cc: Edward Lewis <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Tue, 18 Feb 2003 16:09:06 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 18 Feb 2003 09:45:12 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry
Sender: [email-masked]

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

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

To: Edward Lewis <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Tue, 18 Feb 2003 08:15:40 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

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: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>
Cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry
Date: Tue, 18 Feb 2003 07:30:39 -0500
Sender: [email-masked]

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

I'd certainly like to pursue this.  The exact syntax is described completely
in the schema, and each element is described in the text.  If we can beef
this up to address the IESG's concern then I'm all for it, but I'd like to
know where they feel something is lacking.

-Scott-

Date: Tue, 18 Feb 2003 11:12:58 +0800
To: "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry
Cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, "[email-masked]'"	 <[email-masked]>
Sender: [email-masked]

At 14:42 -0500 2/13/03, Hollenbeck, Scott wrote:
>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?

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

Date: Fri, 14 Feb 2003 14:49:36 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] just to let y'all know
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I want to keep up to date with the current discussion, but I'll be 
unavailable for a few days - I'm travelling to APRICOT.  The 'black 
out' is a bit longer as we'll be setting up for the pre-conference 
tutorials and I don't know when the IP will be turned on...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Thu, 13 Feb 2003 15:18:56 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

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

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

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

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: "Hollenbeck, Scott" <[email-masked]>
To: "'Eric Brunner-Williams in Portland Maine'" <[email-masked]>
Cc: "'Edward Lewis'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry
Date: Thu, 13 Feb 2003 14:42:29 -0500
Sender: [email-masked]

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

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Edward Lewis'" <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Thu, 13 Feb 2003 14:28:50 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> 
> > This is a good request.  This is one of the missing pieces of the 
> > converstation.
> > 
> > At 11:02 -0500 2/11/03, Eric Brunner-Williams in Portland Maine wrote:
> > >>  The WG should note that implementers of real-world 
> > privacy policies are
> > >>  finding it necessary to add a "do not disclose" element.
> > >
> > >Could someone, possibly an implementor, comment on the 
> > design choice that
> > >did not utilize the <dcp> element, and disclose its 
> > deficiencies? I can
> > >guess, but it would be nice to hear from someone else who 
> > considered it
> > >and found it failed to meet a requirement.
> 
> Is Eric's request behind a thought that we are considering either the
> current DCP functionality, or the "do not disclose"-proposed functionality,
> but not both?  I can easily see a need for both:

I'm a little more transparent than that. Jay Random-Implementor decided to
do something novel.

However, assume non-uniqueness of mechanism, and non-uniformity of existence,
with no fewer than one mechanism defined to be "manditory to implement". What
results are forseeable, asumming anything can be forseen?

> - in some environments, it might be OK for the server operator to say "this
> is what I will/might do with data, and if you as data originator give me
> data you are agreeing to my policy".  We have this in the protocol right now
> with the <dcp> element.

Agreed. The announced data collection policy of the server allows the client
to policy-based selection among servers.

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

The EU DP policy requirement contributions to the W3C's P3P WG and to ccTLD
registry operators, and/or gTLD interested parties, could be different.

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

>                                                           ...  but I'm also
> interested in implementer perspectives.  If you're not publishing a data
> collection policy, is there any specific issue that's driving that decision?

Agree.

I can understand why a company operating under the jurisdiction of the FTC
would NOT want to go beyond the regulatory minima specific to its industry,
as to do so would create an unnecessary duty <not a lawyer, etc.>, or take
the opt-in side, before it (ever) becomes law. 

I can understand why a company operating under the jurisdiction of ICANN
would NOT want to suggest that the ICANN WHOIS TF profoundly lacks clue.
(Their latest proposal requires registrants to respond to postal or fax
spam, not just email spam.)

> I haven't decided what makes sense for the .com and .net registry yet, but
> other people who are using EPP in domain registry operations must have been
> through a decision process.  Come on, people, please let us know what you're
> doing with respect to privacy and data collection and why you're doing it!
> We need some real data points to help close the discussion with the IESG.

Agree.

Eric

To: Edward Lewis <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, "'janusz sienkiewicz'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: [ietf-provreg] Is it "social" or is it "model" or is it "mechanism"?
Date: Thu, 13 Feb 2003 13:08:34 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Oki all,

Back when Ross wrote "Domain Name and Related Definitions", and the latest
copy I have squirreled away in my cache of nuts is -dn-defn-01, May '01 [1],
the defintion offered for "social" and "technical" data was couched in the
language defining the "thick" and "thin" registry models, viz:

   Registry, Thick: A registry in which all of the information
   associated with registered entities, including both technical
   information (information needed to produce zone files) and social
   information (information needed to implement operational, business,
   or legal practices), is stored within the registry repository.

and

   Registry, Thin: A registry in which some element of the social
   information associated with registered entities is distributed
   between a shared registry and the registrars served by the registry.

So in -dn-defn- the model constructed the distinction.

Alternatives models include alternative domain registries, not just
the ICANN gTLD set, and registries that aren't domain registries that
may have a shared-registry model that is object-indifferent.

An alternative to the SRS model constructing what we mean by data of
type 1 and type 2 is to look to the publication mechanism(s). We use
1034/35, and don't mention 954.

An alternative to publication mechanism(s) as a means of constructing
data types (e.g., "social" or "technical"), is meta-data associated
with the data, an approach that is common to both the <dcp> element
form I've proposed, and the <dnp> attribute form the IESG proposes.

A surprisingly large amount of stuff can be published by 1034/35.
We could tighten up "information needed to produce zone files".

A surprisingly large amount of stuff can be published by 954.
We could tighten up "information needed to implement operational,
business, or legal practices".

More care in specification of what is published by 1034/35, and what
is published by 954, doesn't cover publication by other means. It
doesn't cover bulk-transfer. The <recipient> element in the <dcp>
does. Additionally, it doesn't cover correctness, which is equivalent
to defining which instance of a datum is authoritative, and how cache
instances of a datum are made consistent with the authoritative copy.
The <access> element in the <dcp> does. Additionally, it doesn't cover
how long any party (reseller, registrar, registry, others not described,
e.g., ICANN escrow agents) retains any datum, nor what purposes it uses
the datum for during each's period of retention. The <retention> and the
<purpose> elements in the <dcp>, respectively, does.

The IESG's <dnp> attribute provides a binary mechanism for typing. This
has the same limitation as the "more care in specification" approach, and
if scoped, as Scott suggested yesterday, simply reduces those limitations
to a smaller collection of datums -- subsets of the current EPP schemas.

Eric

[1] draft-ietf-provreg-dn-defn-01.txt, expired

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, Eric Brunner-Williams in Portland Maine <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry
Date: Thu, 13 Feb 2003 09:56:54 -0500
Sender: [email-masked]

> This is a good request.  This is one of the missing pieces of the 
> converstation.
> 
> At 11:02 -0500 2/11/03, Eric Brunner-Williams in Portland Maine wrote:
> >>  The WG should note that implementers of real-world 
> privacy policies are
> >>  finding it necessary to add a "do not disclose" element.
> >
> >Could someone, possibly an implementor, comment on the 
> design choice that
> >did not utilize the <dcp> element, and disclose its 
> deficiencies? I can
> >guess, but it would be nice to hear from someone else who 
> considered it
> >and found it failed to meet a requirement.

Is Eric's request behind a thought that we are considering either the
current DCP functionality, or the "do not disclose"-proposed functionality,
but not both?  I can easily see a need for both:

- in some environments, it might be OK for the server operator to say "this
is what I will/might do with data, and if you as data originator give me
data you are agreeing to my policy".  We have this in the protocol right now
with the <dcp> element.

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

I'm not sure that this is a "pick one or the other" situation, but I'm also
interested in implementer perspectives.  If you're not publishing a data
collection policy, is there any specific issue that's driving that decision?

I haven't decided what makes sense for the .com and .net registry yet, but
other people who are using EPP in domain registry operations must have been
through a decision process.  Come on, people, please let us know what you're
doing with respect to privacy and data collection and why you're doing it!
We need some real data points to help close the discussion with the IESG.

-Scott-

To: Edward Lewis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Thu, 13 Feb 2003 08:33:13 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Posting the schema diff wouldn't hurt either.

Date: Wed, 12 Feb 2003 13:47:10 -0500
To: "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry
Cc: "'janusz sienkiewicz'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

Yeah, where I see a conflict is that the original comment is:

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

The comment itself constrains where there is a concern about privacy metadata.

It seems to me that the only real sensitivity is to social data ("in 
principle" as we haven't come to a formal and clear definition of 
what that means - as EBW points out), but the comment doesn't hint at 
this.

At 11:52 -0500 2/11/03, Hollenbeck, Scott wrote:
>>  I would suggest going even further. <doNotDisclose> could be
>>  restricted to
>>  social data only. That practically would restrict the element
>>  to contact
>>  mapping only. <doNotDisclose> applied in domain or host
>>  mapping could lead to
>>  ambigous usage. For example:
>
>[snip]
>
>I suggested this possibility to the IESG back when the topic first came up.
>They've disagreed so far, with the reason being that we're moving from
>technology to policy as soon as we try to interpret where it makes sense.
>
>-Scott-

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

Date: Wed, 12 Feb 2003 13:44:22 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry
Cc: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Sender: [email-masked]

This is a good request.  This is one of the missing pieces of the 
converstation.

At 11:02 -0500 2/11/03, Eric Brunner-Williams in Portland Maine wrote:
>>  The WG should note that implementers of real-world privacy policies are
>>  finding it necessary to add a "do not disclose" element.
>
>Could someone, possibly an implementor, comment on the design choice that
>did not utilize the <dcp> element, and disclose its deficiencies? I can
>guess, but it would be nice to hear from someone else who considered it
>and found it failed to meet a requirement.
>
>Eric

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

To: janusz sienkiewicz <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Tue, 11 Feb 2003 12:23:16 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> I would suggest going even further. <doNotDisclose> could be restricted to
> social data only. 

We all know what social data is, but do we? Ross had a definitial ID on this
earlier, it has been let lapse, because we'd currently no mechanism which is
dependent upon this. So, I suggest a definition of SD is useful (again).

>               ... That practically would restrict the element to contact
> mapping only. 

It makes no sense to speak of "privacy" or "data protection" of domain or
host objects. Nor of contacts that aren't persons (not legal fictions). Not
in 95/46/EU, nor OEDC Guidelines, nor FTC lack-of-rules frameworks.

>           ... <doNotDisclose> applied in domain or host mapping could lead to
> ambigous usage. For example:
> 
> <doNotDisclose>
>     <host:name>
> </doNotDisclose>
> 
> may not be necessary be a privacy statement. It could be a DNS policy statement
> as well.

Correct. This has nothing to do with privacy, it has everything to do with
secret-buys, a product. You can buy "secret-product-name.foo" and only your
registrar and registry will know, until you "go public".

> I don't see any problem with handling very unlikely and potentially ambigous
> privacy statements (domain or host object mapping) within EPP extensions. The
> protocol would still offer reasonable level of _INTEROPERATIBILITY_.

They should return errors. EPP provisions 1034/35 publication systems, and some
possible other publication systems. If someone wants a string-space management
protocol, with secret-exhaustion semantics, let them go somewhere else, its a
distraction from the real issue, publication via 954 and 954bis.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "'janusz sienkiewicz'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry
Date: Tue, 11 Feb 2003 11:52:33 -0500
Sender: [email-masked]

> I would suggest going even further. <doNotDisclose> could be 
> restricted to
> social data only. That practically would restrict the element 
> to contact
> mapping only. <doNotDisclose> applied in domain or host 
> mapping could lead to
> ambigous usage. For example:

[snip]

I suggested this possibility to the IESG back when the topic first came up.
They've disagreed so far, with the reason being that we're moving from
technology to policy as soon as we try to interpret where it makes sense.

-Scott-

Date: Tue, 11 Feb 2003 11:57:05 -0500
From: janusz sienkiewicz <[email-masked]>
Organization: LibertyRMS Co.
To: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry
Sender: [email-masked]

Please see my comments below:

"Hollenbeck, Scott" wrote:

> > At the DNR-forum at RIPE-44 last week, the polish registry presented
> > their implementation of EPP. They had to make extensions to implement
> > the somewhat draconian Polish privacy rules. One of the things they
> > mentioned was that they were more severe then the European ones,
> > so when they join the EC, they might change. Anyway, I don't have
> > the presentation on line yet, but they have piblished a document
> > about the things they did with the protocol. It can be found as
> > ascii (http://www.dns.pl/NASK-EPP%202.01.txt) or pdf
> > (http://www.dns.pl/NASK-EPP%202.01.pdf) on the web.
>
> While at the CENTR technical forum I listened intently to these and other
> presentations to see how they relate to our ongoing discussion of privacy
> specification and the unresolved comment from the IESG.  The extensions
> described by the folks from NASK include an element that directly relates to
> the IESG comments: their <consentForPublishing> element is described as "it
> specifies whether a private person gives its permission to publish personal
> details in WHOIS database".
>
> We now have two ccTLD registry operators (.pl (above) and .nl (via Jaap))
> who've noted that having a "do not disclose" flag is something that they
> need and can use.  In the case of .pl, where they claim to have very strict
> privacy rules, implementers found that a single high-level element was
> sufficient to mark the content appropriately.  If we had a "do not disclose"
> element in the contact mapping they probably wouldn't have had to add this
> extension.
>
> In the spirit of "rough consensus and running code", maybe this is a
> reasonable compromise.  We have registries implementing privacy policies
> that need some sort of "do not disclose" marker, but maybe we don't really
> need to mark every element -- maybe having an optional <doNotDisclose>
> element in the various <create>, <info>, and <update> structures is all
> that's really needed in the real world.  I'd like to ask the WG members and
> the IESG to consider this possibility.

I would suggest going even further. <doNotDisclose> could be restricted to
social data only. That practically would restrict the element to contact
mapping only. <doNotDisclose> applied in domain or host mapping could lead to
ambigous usage. For example:

<doNotDisclose>
    <host:name>
</doNotDisclose>

may not be necessary be a privacy statement. It could be a DNS policy statement
as well.

I don't see any problem with handling very unlikely and potentially ambigous
privacy statements (domain or host object mapping) within EPP extensions. The
protocol would still offer reasonable level of _INTEROPERATIBILITY_.

>
>
> The WG should note that implementers of real-world privacy policies are
> finding it necessary to add a "do not disclose" element.
>
> The IESG should note that implementers  of real-world privacy policies are
> finding it sufficient to flag a higher-level structure instead of flagging
> individual elements.
>
> Is this a possible way forward?
>
> -Scott-

Janusz Sienkiewicz

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Tue, 11 Feb 2003 11:02:10 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> The WG should note that implementers of real-world privacy policies are
> finding it necessary to add a "do not disclose" element.

Could someone, possibly an implementor, comment on the design choice that
did not utilize the <dcp> element, and disclose its deficiencies? I can
guess, but it would be nice to hear from someone else who considered it
and found it failed to meet a requirement.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry
Date: Tue, 11 Feb 2003 08:30:20 -0500
Sender: [email-masked]

> At the DNR-forum at RIPE-44 last week, the polish registry presented
> their implementation of EPP. They had to make extensions to implement
> the somewhat draconian Polish privacy rules. One of the things they
> mentioned was that they were more severe then the European ones,
> so when they join the EC, they might change. Anyway, I don't have
> the presentation on line yet, but they have piblished a document
> about the things they did with the protocol. It can be found as
> ascii (http://www.dns.pl/NASK-EPP%202.01.txt) or pdf
> (http://www.dns.pl/NASK-EPP%202.01.pdf) on the web.

While at the CENTR technical forum I listened intently to these and other
presentations to see how they relate to our ongoing discussion of privacy
specification and the unresolved comment from the IESG.  The extensions
described by the folks from NASK include an element that directly relates to
the IESG comments: their <consentForPublishing> element is described as "it
specifies whether a private person gives its permission to publish personal
details in WHOIS database".

We now have two ccTLD registry operators (.pl (above) and .nl (via Jaap))
who've noted that having a "do not disclose" flag is something that they
need and can use.  In the case of .pl, where they claim to have very strict
privacy rules, implementers found that a single high-level element was
sufficient to mark the content appropriately.  If we had a "do not disclose"
element in the contact mapping they probably wouldn't have had to add this
extension.

In the spirit of "rough consensus and running code", maybe this is a
reasonable compromise.  We have registries implementing privacy policies
that need some sort of "do not disclose" marker, but maybe we don't really
need to mark every element -- maybe having an optional <doNotDisclose>
element in the various <create>, <info>, and <update> structures is all
that's really needed in the real world.  I'd like to ask the WG members and
the IESG to consider this possibility.

The WG should note that implementers of real-world privacy policies are
finding it necessary to add a "do not disclose" element.

The IESG should note that implementers  of real-world privacy policies are
finding it sufficient to flag a higher-level structure instead of flagging
individual elements.

Is this a possible way forward?

-Scott-

To: Edward Lewis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] Resend: Just checking ... 
Date: Mon, 03 Feb 2003 11:49:08 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> >Are any other mechanisms proposed?
> 
> I think you've got the proposed mechanisms...

OK. Thanks for the ACK.

Date: Mon, 3 Feb 2003 11:05:31 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] Resend: Just checking ...
Cc: [email-masked]
Sender: [email-masked]

At 9:09 -0500 2/2/03, Eric Brunner-Williams in Portland Maine wrote:
>All,
>
>Since Ed runs about a week behind in responding to list traffic, I'll
>be happy with a response from any contributor.

Sorry about that, but it's true...

>Are any other mechanisms proposed?

I think you've got the proposed mechanisms...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

To: [email-masked]
Subject: [ietf-provreg] Resend: Just checking ...
Date: Sun, 02 Feb 2003 09:09:24 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

All,

Since Ed runs about a week behind in responding to list traffic, I'll
be happy with a response from any contributor.

Eric

------- Forwarded Message

To: [email-masked]
cc: [email-masked]
Subject: [ietf-provreg] Just checking ...
Date: Fri, 31 Jan 2003 20:02:00 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]
Precedence: bulk

Ed,

Is it the case that the following mechanisms are proposed:

	o an attribute, of type boolean, for every element

	o an extensible element, of type epp:dcpType, optionally
	  for any element of type epp:greetingType, extensible
	  to any extensible element

Are any other mechanisms proposed?

Eric

------- End of Forwarded Message

To: Otmar Lendl <[email-masked]>
cc: [email-masked], [email-masked]
Subject: [ietf-provreg] Re: nic.at and nic.pl implementations
Date: Sat, 01 Feb 2003 17:01:40 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

My complements to the implementors!

Today's NY Times (US) reports that MicroSoft has announced a modification
of its product(s) in response to European data protection requirements.

I'm curious to know what the .pl requirements are -- I'm familiar with the
EU requirements.

Cheers,
Eric

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

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

To: Jaap Akkerhuis <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [ietf-provreg] FYI: EPP implementation by the Polish registry 
Date: Sat, 01 Feb 2003 13:06:31 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

kwel!

To: [email-masked]
Subject: [ietf-provreg] FYI: EPP implementation by the Polish registry
Date: Sat, 01 Feb 2003 18:51:49 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

At the DNR-forum at RIPE-44 last week, the polish registry presented
their implementation of EPP. They had to make extensions to implement
the somewhat draconian Polish privacy rules. One of the things they
mentioned was that they were more severe then the European ones,
so when they join the EC, they might change. Anyway, I don't have
the presentation on line yet, but they have piblished a document
about the things they did with the protocol. It can be found as
ascii (http://www.dns.pl/NASK-EPP%202.01.txt) or pdf
(http://www.dns.pl/NASK-EPP%202.01.pdf) on the web.

	jaap

To: [email-masked]
cc: [email-masked]
Subject: [ietf-provreg] Just checking ...
Date: Fri, 31 Jan 2003 20:02:00 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed,

Is it the case that the following mechanisms are proposed:

	o an attribute, of type boolean, for every element

	o an extensible element, of type epp:dcpType, optionally
	  for any element of type epp:greetingType, extensible
	  to any extensible element

Are any other mechanisms proposed?

Eric