[ietf-provreg] Just checking ...

[Eric Brunner-Williams in Portland Maine <[e-mail]>]

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VKm09p029850 for <[e-mail]>; Fri, 31 Jan 2003 21:48:00 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0VKm0Qe029849 for ietf-provreg-outgoing; Fri, 31 Jan 2003 21:48:00 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VKlx9p029844 for <[e-mail]>; Fri, 31 Jan 2003 21:47:59 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h0VKlwYm066247; Fri, 31 Jan 2003 15:47:58 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id PAA14165; Fri, 31 Jan 2003 15:47:57 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b02ba608d85159e@[192.149.252.226]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 31 Jan 2003 15:33:26 -0500
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] preparing a meeting slot request
Cc: Edward Lewis <[e-mail]>, [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

I'd rather leave it as a blocker.  There's a possibility of an 
overlap that may prove to be untrue, but I'd rather find out through 
discussions that by denying it might exist.

At 14:14 -0500 1/31/03, Eric Brunner-Williams in Portland Maine wrote:
>>  CRISP, DNSEXT, DNSOP, ENUM, GEOPRIV, and IPSECKEY (if it becomes something).
>                               ^^^^^^^
>			      GEOPRIV shouldn't be a blocker.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VJZV9p029256 for <[e-mail]>; Fri, 31 Jan 2003 20:35:31 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0VJZURH029255 for ietf-provreg-outgoing; Fri, 31 Jan 2003 20:35:30 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VJZT9p029250 for <[e-mail]>; Fri, 31 Jan 2003 20:35:29 +0100 (MET)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h0VJZPRS020151; Fri, 31 Jan 2003 14:35:25 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Rick Wesson <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, Edward Lewis <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] preparing a meeting slot request 
In-Reply-To: Your message of "Fri, 31 Jan 2003 11:24:22 PST." <[e-mail]> 
Date: Fri, 31 Jan 2003 14:35:25 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

I am aware of similarity. The word "privacy" exists in both contexts.

It just means that the liklihood of having a signal-to-noise ratio we
all desire may be modified.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VJOP9p029151 for <[e-mail]>; Fri, 31 Jan 2003 20:24:25 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h0VJOP3U029150 for ietf-provreg-outgoing; Fri, 31 Jan 2003 20:24:25 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VJON9p029145 for <[e-mail]>; Fri, 31 Jan 2003 20:24:24 +0100 (MET)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id h0VJONmn009830; Fri, 31 Jan 2003 11:24:23 -0800 (PST)
Date: Fri, 31 Jan 2003 11:24:22 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
cc: Edward Lewis <[e-mail]>, <[e-mail]>
Subject: Re: [ietf-provreg] preparing a meeting slot request 
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

yes it should -- they are the only folks tasked with privacy in a simular
context as we were/are.

-rick

On Fri, 31 Jan 2003, Eric Brunner-Williams in Portland Maine wrote:

> > CRISP, DNSEXT, DNSOP, ENUM, GEOPRIV, and IPSECKEY (if it becomes something).
>                               ^^^^^^^
> 			      GEOPRIV shouldn't be a blocker.
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VJEq9p029039 for <[e-mail]>; Fri, 31 Jan 2003 20:14:52 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0VJEqMP029038 for ietf-provreg-outgoing; Fri, 31 Jan 2003 20:14:52 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VJEo9p029033 for <[e-mail]>; Fri, 31 Jan 2003 20:14:50 +0100 (MET)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h0VJEnRS020094; Fri, 31 Jan 2003 14:14:49 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: [e-mail], [e-mail]
Subject: Re: [ietf-provreg] preparing a meeting slot request 
In-Reply-To: Your message of "Fri, 31 Jan 2003 13:25:16 EST." <a05111b11ba606faa1f3b@[192.149.252.226]> 
Date: Fri, 31 Jan 2003 14:14:49 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> CRISP, DNSEXT, DNSOP, ENUM, GEOPRIV, and IPSECKEY (if it becomes something).
                              ^^^^^^^
			      GEOPRIV shouldn't be a blocker.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VIPS9p028435 for <[e-mail]>; Fri, 31 Jan 2003 19:25:28 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h0VIPSHQ028434 for ietf-provreg-outgoing; Fri, 31 Jan 2003 19:25:28 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VIPR9p028429 for <[e-mail]>; Fri, 31 Jan 2003 19:25:27 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h0VIPMYm062058 for <[e-mail]>; Fri, 31 Jan 2003 13:25:25 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA25251; Fri, 31 Jan 2003 13:25:20 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b11ba606faa1f3b@[192.149.252.226]>
Date: Fri, 31 Jan 2003 13:25:16 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] preparing a meeting slot request
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Please let me know if you see any WG's we need to avoid a conflict 
with in SF.  The list I have so far is:

CRISP, DNSEXT, DNSOP, ENUM, GEOPRIV, and IPSECKEY (if it becomes something).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VGr39p027479 for <[e-mail]>; Fri, 31 Jan 2003 17:53:03 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0VGr3T2027477 for ietf-provreg-outgoing; Fri, 31 Jan 2003 17:53:03 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VGr19p027471 for <[e-mail]>; Fri, 31 Jan 2003 17:53:02 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA07628; Fri, 31 Jan 2003 11:52:54 -0500 (EST)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1A37892G>; Fri, 31 Jan 2003 11:49:26 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>
Cc: [e-mail]
Subject: RE: [ietf-provreg] provreg milestones
Date: Fri, 31 Jan 2003 11:49:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> I won't have access to setting one up for pretty much the month of 
> February.  Would anyone like to volunteer a conference bridge and see 
> if we can find a time slot most of us can live with?

I'll volunteer to set up a conference bridge.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VGSe9p027194 for <[e-mail]>; Fri, 31 Jan 2003 17:28:40 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h0VGSeXE027193 for ietf-provreg-outgoing; Fri, 31 Jan 2003 17:28:40 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VGSd9p027188 for <[e-mail]>; Fri, 31 Jan 2003 17:28:39 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h0VGSdYm057511; Fri, 31 Jan 2003 11:28:39 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA07057; Fri, 31 Jan 2003 11:28:30 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0dba6051eb262d@[192.149.252.226]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 31 Jan 2003 11:28:23 -0500
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] provreg milestones
Cc: Edward Lewis <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Yes, that's a point.

In my personal experience in IETF-style discussions, there have been 
times when a 'A vs. B' thread trails on indefinitely.  Looking back 
at those, what I've come to realize is that the participants are 
often way too focused on the 'A vs. B' and not looking at why there's 
a competition.

This might be the case with the privacy 'thing.'  (Thing - the issues 
surrounding the answer to 'that' IESG comment.)  Perhaps we need to 
step back, address the context, and then dive in again.

How to overcome this needs discussion.  I've been squeezed schedule 
wise to set anything up other than rely on the mailing list.  I think 
that we need to have some non-text based communications on this and 
waiting until March isn't desirable.

My schedule gets nasty starting next week.  I'm on the road from the 
4th-12th and 15th-26th of February and then the 9th of March until 
after the IETF.  (The usual Internet winter road show.)  Perhaps it 
would be beneficial if we had an interim telecon to talk about 
solving this.  Not about how to address the IESG comment per se - 
like what XML to do - but what we think we can consider.

I won't have access to setting one up for pretty much the month of 
February.  Would anyone like to volunteer a conference bridge and see 
if we can find a time slot most of us can live with?

At 10:55 -0500 1/31/03, Eric Brunner-Williams in Portland Maine wrote:
>Ed,
>
>In the muddle of privacy/dataprotection/security/mumble, we've the
>minor problem of whether the contributors to this WG are specifying
>is a protocol which performs onward-transport of data acquired by
>some other mechanism(s), or is a protocol which performs acquisition
>of data (in the IESG model the data is meta-data) in addition to the
>onward-transport function.
>
>Little substantive communication on this subject is taking place on
>the mailing list. That's a problem that can't be solved in San Fran.
>
>Eric

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VFtB9p026828 for <[e-mail]>; Fri, 31 Jan 2003 16:55:11 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0VFtB5N026827 for ietf-provreg-outgoing; Fri, 31 Jan 2003 16:55:11 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VFtA9p026822 for <[e-mail]>; Fri, 31 Jan 2003 16:55:10 +0100 (MET)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h0VFt9RS019650; Fri, 31 Jan 2003 10:55:09 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: [ietf-provreg] provreg milestones 
In-Reply-To: Your message of "Fri, 31 Jan 2003 10:14:40 EST." <a05111b08ba6041263747@[192.149.252.226]> 
Date: Fri, 31 Jan 2003 10:55:09 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Ed,

In the muddle of privacy/dataprotection/security/mumble, we've the
minor problem of whether the contributors to this WG are specifying
is a protocol which performs onward-transport of data acquired by
some other mechanism(s), or is a protocol which performs acquisition
of data (in the IESG model the data is meta-data) in addition to the
onward-transport function.

Little substantive communication on this subject is taking place on
the mailing list. That's a problem that can't be solved in San Fran.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VFhI9p026696 for <[e-mail]>; Fri, 31 Jan 2003 16:43:18 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h0VFhIDv026695 for ietf-provreg-outgoing; Fri, 31 Jan 2003 16:43:18 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VFhH9p026690 for <[e-mail]>; Fri, 31 Jan 2003 16:43:17 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA03834; Fri, 31 Jan 2003 10:43:05 -0500 (EST)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1A3787HR>; Fri, 31 Jan 2003 10:39:37 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: [ietf-provreg] provreg milestones
Date: Fri, 31 Jan 2003 10:39:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Ed,

Works for me -- it sounds like we might want to discuss transports and
interoperability testing in San Francisco.

-Scott- 

> -----Original Message-----
> From: Edward Lewis [mailto:[e-mail]]
> Sent: Friday, January 31, 2003 10:15 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: [ietf-provreg] provreg milestones
> 
> 
> While we still have an open issue with regards to privacy, I want to 
> move on and at least refresh the group's milestones.
> 
> FEB 03 Respond to the IESG Comments (for Proposed)
> MAR 03 Submit Guidelines for Extending the EPP to IESG (Informational)
> APR 03 Decision on Alternate Transports
> SEP 03 Perform Interoperability Tests
> OCT 03 Submit Interoperability Report to IESG (Informational)
> OCT 03 Submit Extensible Provisioning Protocol to IESG (Draft)
> OCT 03 Submit EPP Contact Mapping to IESG (Draft)
> OCT 03 Submit EPP Domain Name Mapping to IESG (Draft)
> OCT 03 Submit EPP Host Mapping to IESG (Draft)
> OCT 03 Submit EPP Transport Over TCP to IESG (Draft)

[snip]


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VFEi9p026431 for <[e-mail]>; Fri, 31 Jan 2003 16:14:44 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0VFEi7D026430 for ietf-provreg-outgoing; Fri, 31 Jan 2003 16:14:44 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VFEg9p026425 for <[e-mail]>; Fri, 31 Jan 2003 16:14:43 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h0VFEgYm054778; Fri, 31 Jan 2003 10:14:42 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA26809; Fri, 31 Jan 2003 10:14:41 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b08ba6041263747@[192.149.252.226]>
Date: Fri, 31 Jan 2003 10:14:40 -0500
To: [e-mail], [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] provreg milestones
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

While we still have an open issue with regards to privacy, I want to 
move on and at least refresh the group's milestones.

FEB 03 Respond to the IESG Comments (for Proposed)
MAR 03 Submit Guidelines for Extending the EPP to IESG (Informational)
APR 03 Decision on Alternate Transports
SEP 03 Perform Interoperability Tests
OCT 03 Submit Interoperability Report to IESG (Informational)
OCT 03 Submit Extensible Provisioning Protocol to IESG (Draft)
OCT 03 Submit EPP Contact Mapping to IESG (Draft)
OCT 03 Submit EPP Domain Name Mapping to IESG (Draft)
OCT 03 Submit EPP Host Mapping to IESG (Draft)
OCT 03 Submit EPP Transport Over TCP to IESG (Draft)

Look these over carefully.  I added the first because we haven't 
closed that off, as well as having some potential threads to cover in 
addition to the privacy question.

A "Decision on Alternate Transports" is on there because our charter 
talks about  "support for multiple operational choices, such as for 
transport".  At times support has been expressed for BEEP, SMTP, and 
SOAP, but none have garnered much support.  My vague opinion is that 
alternate transports will need to come with code, not just documents, 
before they can be taken seriously by the WG.

Note that SMTP and SOAP milestones are not on there.  Not to 
denigrate the work, but they haven't made it to general interest for 
the WG.

With this message I am asking our AD to approve these milestones, we 
can adjust them as necessary.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VClr9p025131 for <[e-mail]>; Fri, 31 Jan 2003 13:47:53 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h0VClrn7025130 for ietf-provreg-outgoing; Fri, 31 Jan 2003 13:47:53 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0VClp9p025125 for <[e-mail]>; Fri, 31 Jan 2003 13:47:52 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA26495 for <[e-mail]>; Fri, 31 Jan 2003 07:47:44 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <1AMXVHNL>; Fri, 31 Jan 2003 07:46:09 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: [e-mail]
Subject: RE: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-08.txt
Date: Fri, 31 Jan 2003 07:44:16 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I've updated the "out-of-document" schema files and examples that correspond
to the latest protocol drafts.  Copies can be found here:

http://www.verisign-grs.com/files/

and here:

ftp://ftp.verisign.com/pub/epp/20030129/

-Scott-

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, January 30, 2003 7:54 AM
> To: IETF-Announce; @cafax.se
> Cc: [e-mail]
> Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-08.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Provisioning Registry 
> Protocol Working Group of the IETF.
> 
> 	Title		: Extensible Provisioning Protocol
> 	Author(s)	: S. Hollenbeck
> 	Filename	: draft-ietf-provreg-epp-08.txt
> 	Pages		: 75
> 	Date		: 2003-1-29
> 	
> This document describes an application layer client-server protocol
> for the provisioning and management of objects stored in a shared
> central repository.  Specified in XML, the protocol defines generic
> object management operations and an extensible framework that maps
> protocol operations to objects.  This document includes a protocol
> specification, an object mapping template, and an XML media type
> registration.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0UCwI9p012547 for <[e-mail]>; Thu, 30 Jan 2003 13:58:18 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0UCwI0b012546 for ietf-provreg-outgoing; Thu, 30 Jan 2003 13:58:18 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0UCwG9p012541 for <[e-mail]>; Thu, 30 Jan 2003 13:58:16 +0100 (MET)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26097; Thu, 30 Jan 2003 07:54:43 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-tcp-06.txt
Date: Thu, 30 Jan 2003 07:54:42 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Transport Over TCP
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-tcp-06.txt
	Pages		: 13
	Date		: 2003-1-29
	
This document describes how an Extensible Provisioning Protocol (EPP)
session is mapped onto a single Transmission Control Protocol (TCP)
connection.  This mapping requires use of the Transport Layer Security
(TLS) Protocol to protect information exchanged between an EPP client
and an EPP server.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-tcp-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-tcp-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-tcp-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-tcp-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-tcp-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0UCwF9p012538 for <[e-mail]>; Thu, 30 Jan 2003 13:58:15 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0UCwFNm012537 for ietf-provreg-outgoing; Thu, 30 Jan 2003 13:58:15 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0UCwA9p012532 for <[e-mail]>; Thu, 30 Jan 2003 13:58:11 +0100 (MET)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26068; Thu, 30 Jan 2003 07:54:37 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-host-06.txt
Date: Thu, 30 Jan 2003 07:54:37 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Host Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-host-06.txt
	Pages		: 33
	Date		: 2003-1-29
	
This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of Internet host names
stored in a shared central repository.  Specified in XML, the mapping
defines EPP command syntax and semantics as applied to host names.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-host-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-host-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-host-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-host-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-host-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0UCw99p012530 for <[e-mail]>; Thu, 30 Jan 2003 13:58:09 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h0UCw9OE012529 for ietf-provreg-outgoing; Thu, 30 Jan 2003 13:58:09 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0UCw59p012524 for <[e-mail]>; Thu, 30 Jan 2003 13:58:05 +0100 (MET)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26048; Thu, 30 Jan 2003 07:54:32 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-domain-06.txt
Date: Thu, 30 Jan 2003 07:54:31 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Domain Name Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-domain-06.txt
	Pages		: 47
	Date		: 2003-1-29
	
This document describes an Extensible Provisioning Protocol (EPP) map-
ping for the provisioning and management of Internet domain names
stored in a shared central repository.  Specified in XML, the mapping
defines EPP command syntax and semantics as applied to domain names

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-domain-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-domain-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-domain-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-domain-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-domain-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0UCw19p012522 for <[e-mail]>; Thu, 30 Jan 2003 13:58:01 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0UCw1h1012521 for ietf-provreg-outgoing; Thu, 30 Jan 2003 13:58:01 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0UCw09p012516 for <[e-mail]>; Thu, 30 Jan 2003 13:58:00 +0100 (MET)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26030; Thu, 30 Jan 2003 07:54:26 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-contact-06.txt
Date: Thu, 30 Jan 2003 07:54:26 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol Contact Mapping
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-contact-06.txt
	Pages		: 43
	Date		: 2003-1-29
	
This document describes an Extensible Provisioning Protocol (EPP)
mapping for the provisioning and management of individual or
organizational social information identifiers (known as 'contacts')
stored in a shared central repository. Specified in XML, the mapping
defines EPP command syntax and semantics as applied to contacts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-contact-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-contact-06.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-contact-06.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-contact-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-contact-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0UCvw9p012514 for <[e-mail]>; Thu, 30 Jan 2003 13:57:58 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0UCvwpO012513 for ietf-provreg-outgoing; Thu, 30 Jan 2003 13:57:58 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0UCvt9p012508 for <[e-mail]>; Thu, 30 Jan 2003 13:57:56 +0100 (MET)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26012; Thu, 30 Jan 2003 07:54:21 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-08.txt
Date: Thu, 30 Jan 2003 07:54:21 -0500
Sender: [e-mail]
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Provisioning Registry Protocol Working Group of the IETF.

	Title		: Extensible Provisioning Protocol
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-08.txt
	Pages		: 75
	Date		: 2003-1-29
	
This document describes an application layer client-server protocol
for the provisioning and management of objects stored in a shared
central repository.  Specified in XML, the protocol defines generic
object management operations and an extensible framework that maps
protocol operations to objects.  This document includes a protocol
specification, an object mapping template, and an XML media type
registration.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-08.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-provreg-epp-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-provreg-epp-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-provreg-epp-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0OKFw9p014492 for <[e-mail]>; Fri, 24 Jan 2003 21:15:58 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h0OKFw8g014491 for ietf-provreg-outgoing; Fri, 24 Jan 2003 21:15:58 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0OKFv9p014486 for <[e-mail]>; Fri, 24 Jan 2003 21:15:57 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id PAA02587; Fri, 24 Jan 2003 15:15:50 -0500 (EST)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <DBRZDLMV>; Fri, 24 Jan 2003 15:12:43 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Subject: RE: [ietf-provreg] draft's expiring
Date: Fri, 24 Jan 2003 15:13:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> Scott - would you put out a new version of the documents based on 
> answers to the IESG comments settled to date?  Leave the privacy 
> issue unaddressed (ie no edits regarding the granularity) and the 
> other issues that are hanging around.

Sure -- I can have them done next week.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0OJkf9p014271 for <[e-mail]>; Fri, 24 Jan 2003 20:46:41 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0OJkfb9014270 for ietf-provreg-outgoing; Fri, 24 Jan 2003 20:46:41 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0OJkd9p014265 for <[e-mail]>; Fri, 24 Jan 2003 20:46:40 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h0OJkaYm088482 for <[e-mail]>; Fri, 24 Jan 2003 14:46:37 -0500 (EST)
Received: from [192.149.252.226] ([192.149.252.226]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA28048; Fri, 24 Jan 2003 14:46:36 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b0bba574249a112@[192.149.252.226]>
Date: Fri, 24 Jan 2003 14:22:41 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] draft's expiring
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

We have been haggling over the IESG comments for so long now (and for 
good reason) that we are slowly closing in on the expiration (Feb. 
19) of the set of documents under consideration.

Scott - would you put out a new version of the documents based on 
answers to the IESG comments settled to date?  Leave the privacy 
issue unaddressed (ie no edits regarding the granularity) and the 
other issues that are hanging around.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0NL5q9p003475 for <[e-mail]>; Thu, 23 Jan 2003 22:05:52 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0NL5qhM003474 for ietf-provreg-outgoing; Thu, 23 Jan 2003 22:05:52 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0NL5j9p003469 for <[e-mail]>; Thu, 23 Jan 2003 22:05:46 +0100 (MET)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h0NL657k044641; Thu, 23 Jan 2003 16:06:05 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: Vittorio Bertola <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] where are we with privacy 
In-Reply-To: Your message of "Thu, 23 Jan 2003 11:06:16 EST." <a05111b05ba55bfef24b2@[192.149.252.226]> 
Date: Thu, 23 Jan 2003 16:06:05 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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)


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0NG7G9p029604 for <[e-mail]>; Thu, 23 Jan 2003 17:07:16 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h0NG7GL9029603 for ietf-provreg-outgoing; Thu, 23 Jan 2003 17:07:16 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0NG799p029594 for <[e-mail]>; Thu, 23 Jan 2003 17:07:10 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h0NG6nYm039446; Thu, 23 Jan 2003 11:06:50 -0500 (EST)
Received: from [192.149.252.226] ([192.149.252.226]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA01775; Thu, 23 Jan 2003 11:06:48 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@ops
Message-Id: <a05111b05ba55bfef24b2@[192.149.252.226]>
In-Reply-To: <[e-mail]>
References: <a05111b03ba509fa53c14@[204.152.189.28]> <[e-mail]>
Date: Thu, 23 Jan 2003 11:06:16 -0500
To: Vittorio Bertola <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: [ietf-provreg] where are we with privacy
Cc: Edward Lewis <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 10:42 +0100 1/23/03, Vittorio Bertola wrote:
>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.)

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?

>>4) The proposed "doNotDisclose" mechanism seems to work with some
>>environments, but the wording/name of it is a bit ambiguous.
>
>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.

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

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.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0NCFL9p027134 for <[e-mail]>; Thu, 23 Jan 2003 13:15:21 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0NCFLvd027133 for ietf-provreg-outgoing; Thu, 23 Jan 2003 13:15:21 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0NCFK9p027128 for <[e-mail]>; Thu, 23 Jan 2003 13:15:20 +0100 (MET)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h0NCFe7k043468; Thu, 23 Jan 2003 07:15:40 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Vittorio Bertola <[e-mail]>
cc: Edward Lewis <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] where are we with privacy 
In-Reply-To: Your message of "Thu, 23 Jan 2003 10:42:36 +0100." <[e-mail]> 
Date: Thu, 23 Jan 2003 07:15:40 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

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.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0N9g49p025960 for <[e-mail]>; Thu, 23 Jan 2003 10:42:04 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h0N9g3NB025959 for ietf-provreg-outgoing; Thu, 23 Jan 2003 10:42:04 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from lazzaro.bertola.eu.org (net-197-95.noicomnet.it [194.153.197.95]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id h0N9g29p025954 for <[e-mail]>; Thu, 23 Jan 2003 10:42:02 +0100 (MET)
Received: (qmail 12506 invoked from network); 23 Jan 2003 09:48:54 -0000
Received: from unknown (HELO PIETRO) (10.0.1.2) by 0 with SMTP; 23 Jan 2003 09:48:54 -0000
From: Vittorio Bertola <[e-mail]>
To: Edward Lewis <[e-mail]>
Cc: [e-mail]
Subject: Re: [ietf-provreg] where are we with privacy
Date: Thu, 23 Jan 2003 10:42:36 +0100
Message-ID: <[e-mail]>
References: <a05111b03ba509fa53c14@[204.152.189.28]>
In-Reply-To: <a05111b03ba509fa53c14@[204.152.189.28]>
X-Mailer: Forte Agent 1.9/32.560
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h0N9g39p025955
Sender: [e-mail]
Precedence: bulk

On Sun, 19 Jan 2003 21:00:15 -0500, you wrote:

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

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

>4) The proposed "doNotDisclose" mechanism seems to work with some 
>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/ <-----------------------



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0M0m39p010416 for <[e-mail]>; Wed, 22 Jan 2003 01:48:03 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0M0m3cu010415 for ietf-provreg-outgoing; Wed, 22 Jan 2003 01:48:03 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0M0m19p010409 for <[e-mail]>; Wed, 22 Jan 2003 01:48:02 +0100 (MET)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h0M0mp7k038586; Tue, 21 Jan 2003 19:48:51 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: "Hollenbeck, Scott" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] where are we with privacy 
In-Reply-To: Your message of "Tue, 21 Jan 2003 11:36:52 EST." <a05111b02ba53173826c6@[192.149.252.226]> 
Date: Tue, 21 Jan 2003 19:48:51 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> I would also like others to comment on Jaap's message and assessment that:

OK, part 2.

> At 13:43 +0100 1/10/03, Jaap Akkerhuis wrote:
> ...
> >So yes, the non-disclose attribute will work for us without any
> >problem. It is possible that we might do extensions to aid with the
> ...
> >
> >	jaap

\begin{quote}
Deelnemers
...
Deelnemer worden
...
Deelnemers categorie I
	Voor het deelnemerschap categorie I komen in aanmerking
	bedrijven in instellingen die zijn gevestigd op het grondgebied
	van de Euorpese Unie.

	[Category I participation Category I participation is open
	to businesses and institutions based within the European Union.] 

	...

	Het deelnemerschap geeft recht tot:

		o het verzorgen van de registratie van domeinnamen ten
		  behoeve van klanten;

	[Category I participants have the following rights:

		o To apply to register domain names on behalf of
		  clients;]
\end{quote}

The "us" (parties having the capacity to register domain names on behalf
of clients) for which "the non-disclose attribute will work" appears to
be a scoped set of (eventual) EPP participants. The charter for this WG
is not to create a registry-specific, or regime-specific, or jurisdiction-
specific, or object-specific protocol.

How can a registrar signal in-band to a registry that it accepts the general
Data Protection framework, and any specific terms and conditions?

More generally, how can any two (or more) participants in the onward-transport
of customer data signal in-band their data collection practices, and automate
the management of onward-transport?

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0LNDs9p009817 for <[e-mail]>; Wed, 22 Jan 2003 00:13:54 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h0LNDsK3009816 for ietf-provreg-outgoing; Wed, 22 Jan 2003 00:13:54 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0LNDr9p009811 for <[e-mail]>; Wed, 22 Jan 2003 00:13:53 +0100 (MET)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h0LNEg7k038387; Tue, 21 Jan 2003 18:14:42 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Eric Brunner-Williams in Portland Maine <[e-mail]>
cc: Edward Lewis <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] where are we with privacy 
In-Reply-To: Your message of "Tue, 21 Jan 2003 14:05:35 EST." <[e-mail]> 
Date: Tue, 21 Jan 2003 18:14:42 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

opps. a dot de trops.

s/\.EU/EU/

sorry if anyone was confused.

eric
(who put the "dot" in dotty)


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0LJ4l9p007489 for <[e-mail]>; Tue, 21 Jan 2003 20:04:47 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h0LJ4lvC007488 for ietf-provreg-outgoing; Tue, 21 Jan 2003 20:04:47 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0LJ4k9p007483 for <[e-mail]>; Tue, 21 Jan 2003 20:04:46 +0100 (MET)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h0LJ5Z7k037804; Tue, 21 Jan 2003 14:05:35 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: "Hollenbeck, Scott" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: [ietf-provreg] where are we with privacy 
In-Reply-To: Your message of "Tue, 21 Jan 2003 11:36:52 EST." <a05111b02ba53173826c6@[192.149.252.226]> 
Date: Tue, 21 Jan 2003 14:05:35 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> I would also like others to comment on Jaap's message and assessment that:

OK.

> At 13:43 +0100 1/10/03, Jaap Akkerhuis wrote:
> ...
> >So yes, the non-disclose attribute will work for us without any
> >problem. It is possible that we might do extensions to aid with the
> ...
> >
> >	jaap

1. Application of the IESG proposal to "technical" data.

The .NL registry defines (hypothetically of course) a dnp==true value for
one or more elements as an error condition, and presumably returns some
error code.

Someone, Scott if my memory serves, mentioned a registry which defines a
dnp==true value for one or more elements as a non-error, and presumably
returns something other than an error code.

Is using EPP with dcp==true for technical data a good thing? I see it as
an operation to modify the string-space, with no external manifestation,
other than error upon query or transform. I can't imagine an application
to an address registry's operational practices, but I don't have direct
knowledge of address registry or registrar operational art.

2. Application of the IESG proposal to "social" data at a registry.

The .NL registry anticipates (effective 29 Jan 2003) operating under the
general framework of a European Union member state's Data Protection Act.

Consistent with the general framework of EU's Data Protection Directives,
the access, purpose, recipient, and retention are all contractually defined.

This is not generally the case for registries operating outside of the EU,
nor for registrars and resellers operating outside of the EU.

It would be helpful if the details of data protection between a non-EU
resident .NL regsitrar and the .NL registry were available, assuming any
exist.

3. Existance of the PROVREG proposal, in the presence of the IESG proposal.

Would the .NL registry operator use both the session-level <dcp> data, and
the element-level opt-{in|out} data? If the answer is "no", as I suspect
it is, then <dcp> use either a) is error, or b) is silently discarded.
If the answer is "yes", which takes precidence in the event of conflict?

Trying to keep concrete, data originates from a registrant and is collected
by a US-Reseller, and in turn provisioned to a CA-Registrar, and in turn is
provisioned to a .EU-Registry. Is the mechanism that provides the guidance
for operational art at each onward-transport entity out-of-band (contract),
or is it in-band, and if in-band, did the IESG proposal provide the same
policy at each collector/onward-transporter as the European Union member
state's Data Protection Act?

I don't think so.

I could be wrong.

A p|np toggle is fine if purpose/recipient/retention/access are already
taken care of (the Data Protection case). Where they are not, (OEDC and
US cases), a p|np toggle may solve the 954 problem. How it can be applied
to non-954 (and 954bis) is not stated.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0LHnk9p006696 for <[e-mail]>; Tue, 21 Jan 2003 18:49:46 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0LHnjk4006695 for ietf-provreg-outgoing; Tue, 21 Jan 2003 18:49:45 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0LHnh9p006690 for <[e-mail]>; Tue, 21 Jan 2003 18:49:44 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h0LHnhYm084413; Tue, 21 Jan 2003 12:49:43 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA11856; Tue, 21 Jan 2003 12:49:42 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b07ba53380fd927@[192.149.252.226]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 21 Jan 2003 12:49:08 -0500
To: "Hollenbeck, Scott" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: RE: [ietf-provreg] where are we with privacy
Cc: "'Edward Lewis'" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 11:52 -0500 1/21/03, Hollenbeck, Scott wrote:
>>  I would like to see a better case made for the granular privacy data
>>  specification.  The IESG wants it, but the group is not sold that
>>  this is possible (= worth achieving with the given level of effort
>>  available).
>
>Who should make that case?  If it's the IESG, how do we get them to do so?

I think the IESG, I've been asking questions privately (trying to 
balance openness v. expediency).
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0LGst9p006156 for <[e-mail]>; Tue, 21 Jan 2003 17:54:55 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0LGstTH006155 for ietf-provreg-outgoing; Tue, 21 Jan 2003 17:54:55 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0LGss9p006150 for <[e-mail]>; Tue, 21 Jan 2003 17:54:54 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id LAA03023; Tue, 21 Jan 2003 11:54:48 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <ZHNYLJPR>; Tue, 21 Jan 2003 11:53:34 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>
Cc: [e-mail]
Subject: RE: [ietf-provreg] where are we with privacy
Date: Tue, 21 Jan 2003 11:52:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> I would like to see a better case made for the granular privacy data 
> specification.  The IESG wants it, but the group is not sold that 
> this is possible (= worth achieving with the given level of effort 
> available).

Who should make that case?  If it's the IESG, how do we get them to do so?

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0LGiN9p006061 for <[e-mail]>; Tue, 21 Jan 2003 17:44:23 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h0LGiNcL006060 for ietf-provreg-outgoing; Tue, 21 Jan 2003 17:44:23 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0LGiL9p006055 for <[e-mail]>; Tue, 21 Jan 2003 17:44:21 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h0LGiKYm082279; Tue, 21 Jan 2003 11:44:20 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA01748; Tue, 21 Jan 2003 11:44:19 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b02ba53173826c6@[192.149.252.226]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 21 Jan 2003 11:36:52 -0500
To: "Hollenbeck, Scott" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: RE: [ietf-provreg] where are we with privacy
Cc: "'Edward Lewis'" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 8:49 -0500 1/20/03, Hollenbeck, Scott wrote:
>
>What would you suggest as a way forward?
>

This is the third try at answering this.  The other attempts got 
lengthy and pointless.

I would like to see a better case made for the granular privacy data 
specification.  The IESG wants it, but the group is not sold that 
this is possible (= worth achieving with the given level of effort 
available).

I would also like others to comment on Jaap's message and assessment that:

At 13:43 +0100 1/10/03, Jaap Akkerhuis wrote:
...
>So yes, the non-disclose attribute will work for us without any
>problem. It is possible that we might do extensions to aid with the
...
>
>	jaap

I do see that there are some other messages I haven't read yet in the 
mailbox...I've taken too long thinking about this one, I guess.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0KDq79p022741 for <[e-mail]>; Mon, 20 Jan 2003 14:52:07 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h0KDq7M3022740 for ietf-provreg-outgoing; Mon, 20 Jan 2003 14:52:07 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0KDq59p022735 for <[e-mail]>; Mon, 20 Jan 2003 14:52:05 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id IAA22746; Mon, 20 Jan 2003 08:51:56 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <ZHNYKR5V>; Mon, 20 Jan 2003 08:50:45 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Subject: RE: [ietf-provreg] where are we with privacy
Date: Mon, 20 Jan 2003 08:49:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Edward Lewis [mailto:[e-mail]]
> Sent: Sunday, January 19, 2003 9:00 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [ietf-provreg] where are we with privacy
> 
> 
> 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:

[snip]

What would you suggest as a way forward?

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0K2Gd9p017347 for <[e-mail]>; Mon, 20 Jan 2003 03:16:39 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h0K2GdGq017346 for ietf-provreg-outgoing; Mon, 20 Jan 2003 03:16:39 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp02.mrf.mail.rcn.net (smtp02.mrf.mail.rcn.net [207.172.4.61]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0K2GZ9p017341 for <[e-mail]>; Mon, 20 Jan 2003 03:16:36 +0100 (MET)
Received: from 66-44-67-217.s471.tnt7.lnhva.md.dialup.rcn.com ([66.44.67.217]) by smtp02.mrf.mail.rcn.net with esmtp (Exim 3.35 #4) id 18aRUI-0004HO-00; Sun, 19 Jan 2003 21:16:34 -0500
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1 (Unverified)
Message-Id: <a05111b03ba509fa53c14@[204.152.189.28]>
Date: Sun, 19 Jan 2003 21:00:15 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] where are we with privacy
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0IDOt9p006722 for <[e-mail]>; Sat, 18 Jan 2003 14:24:55 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h0IDOt8p006721 for ietf-provreg-outgoing; Sat, 18 Jan 2003 14:24:55 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0IDOs9p006716 for <[e-mail]>; Sat, 18 Jan 2003 14:24:54 +0100 (MET)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h0IDPkCQ004897; Sat, 18 Jan 2003 08:25:46 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Vittorio Bertola <[e-mail]>
cc: [e-mail], [e-mail]
Subject: [ietf-provreg] Re: An user's point of view on the privacy issue 
In-Reply-To: Your message of "Fri, 17 Jan 2003 11:03:26 +0100." <[e-mail]> 
Date: Sat, 18 Jan 2003 08:25:46 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> I am a newbie of this group and of the IETF WGs in general (please
> pardon me for anything inappropriate I might unvoluntarily do).
> However, I have been discussing DNS privacy issues extensively in the
> last years, so please allow me to give my point of view on the ongoing
> privacy discussion.

About two years ago we (the participants of the provreg wg list at the
time) distinguished between the policy requirements, hence the mechanism
requirements, of prototocols for the provisioning of a shared registry,
and protocols for the publication of data.

Of late, this distinction appears to have been lost.

Publication policy, whether the protocol of publication is 1034/35 et seq.,
or 943 et seq., or any other protocol, simply isn't in scope (unless there
is consensus that it is, or some other controlling actor, and 2026 leaves
me unable to find one) asserts to the contrary.

 Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0HMLI9p001923 for <[e-mail]>; Fri, 17 Jan 2003 23:21:18 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0HMLI5o001922 for ietf-provreg-outgoing; Fri, 17 Jan 2003 23:21:18 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0HMLH9p001917 for <[e-mail]>; Fri, 17 Jan 2003 23:21:17 +0100 (MET)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h0HMLgZ2021203; Fri, 17 Jan 2003 17:21:42 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: Eric Brunner-Williams in Portland Maine <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: [ietf-provreg] Re: document management
In-Reply-To: Your message of "Thu, 09 Jan 2003 10:55:37 EST." <a05111b06ba434aafbd3c@[192.149.252.226]>
Date: Fri, 17 Jan 2003 17:21:42 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> Some background reading:
> 
> http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00099.html

I see Jaap's note 2) "Other transports".

Noting the lack of interest I'll modify the conditional boilerplate in
draft-brunner-epp-smtp-00.txt that anticipated adoption of the memo by
a working group, track dependencies in the set of WG memos, and continue
off-list.

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

No comment required.

> In the last, item #5 lists the three issues of which I'm aware.

2. Come to a final understanding of UDP and EPP.

I'm still not convinced by PAF, or Scott Bradner, but its the opinion of
the other implementors, if any, that is controlling.

3. Clarify the adoption of P3P concepts.

I seem to have missed both the problem statement and the solution.

5. An SMTP mapping is all but dead in the water.

See above.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0HH1b9p029145 for <[e-mail]>; Fri, 17 Jan 2003 18:01:37 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0HH1bdE029144 for ietf-provreg-outgoing; Fri, 17 Jan 2003 18:01:37 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail8.megamailservers.com (mail8.megamailservers.com [216.251.36.18]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0HH1Z9p029134 for <[e-mail]>; Fri, 17 Jan 2003 18:01:35 +0100 (MET)
Received: from rraderxp (dodgy.tucows.com [207.136.98.130]) by mail8.megamailservers.com (8.12.5/8.12.0.Beta10) with ESMTP id h0HH1V2V037998; Fri, 17 Jan 2003 12:01:31 -0500 (EST)
Reply-To: <[e-mail]>
From: "Ross Wm. Rader" <[e-mail]>
To: <[e-mail]>, "'Michael Young'" <[e-mail]>, "'Vittorio Bertola'" <[e-mail]>, <[e-mail]>
Subject: RE: An user's point of view on the privacy issue
Date: Fri, 17 Jan 2003 12:01:31 -0500
Organization: Tucows Inc.
Message-ID: <000d01c2be4a$15b4e830$f80b000a@rraderxp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <000801c2be37$1c9d8840$f80b000a@rraderxp>
Sender: [e-mail]
Precedence: bulk

> Agreed - *but* I don't expect that we'll see many as long as 
> you're up there.

Oops...just re-read that - there was a ":)" that should have ended that
sentence - no ill intended.



                       -rwr




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

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


 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Ross Wm. Rader
> Sent: Friday, January 17, 2003 9:46 AM
> To: 'Michael Young'; 'Vittorio Bertola'; [e-mail]
> Subject: RE: An user's point of view on the privacy issue
> 
> 
> > would like to see less soap-box speechs and more work towards
> 
> Agreed - *but* I don't expect that we'll see many as long as 
> you're up there. I don't know about the rest of you, but I do 
> appreciate Vittorio taking the time out to specify what his 
> requirements for the mechanism might be. Once the smart guys 
> figure out where that should happen, specifications such as 
> his will most undoubtedly help you figure out how to make 
> "what it looks like" work.
> 
> I've dropped out of even lurking for the past few days, but 
> suffice to say that this is all moot if the question is still 
> "who" as per Joe's question of the 8th... And, at the risk of 
> getting ahead of myself, I'm also not sure that I've seen an 
> answer to Andrew's question of the 9th regarding what basic 
> "privacy" actually is. From my standpoint, the entire line of 
> conjecture is a bit of a red herring - it may simplify the 
> discussion to look at this as a data ownership/entity 
> relationship/data rights management issue as opposed to the 
> more charged (and elusive) question of "privacy" - unless 
> someone has a reasonable definition of "privacy" that they 
> haven't shared with us...
> 
> 
> 
>                        -rwr
> 
> 
> 
> 
> "There's a fine line between fishing and standing on the 
> shore like an idiot."
> - Steven Wright
> 
> Get Blog... http://www.byte.org/blog
> 
> 
>  
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Michael Young
> > Sent: Friday, January 17, 2003 8:49 AM
> > To: 'Vittorio Bertola'; [e-mail]
> > Subject: RE: An user's point of view on the privacy issue
> > 
> > 
> > Thank you for providing your opinion on privacy issues
> > Vittorio.  I think you'll find by reviewing the list that the 
> > current debate in the provreg working group is not about 
> > whether or not a privacy mechanism is desirable, but really 
> > about the technical implementation and where that should 
> > happen.  There are multiple approaches to how to solve for 
> > this problem, and all of them have their perceived advantages 
> > and disadvantages. Some approaches that are being heavily 
> > advocated from non-technical stakeholders have some serious 
> > implementation and performance impacts, and that's really 
> > whats at the heart of the debate right now.  BTW in my 
> > opinion, this forum is not meant as a venue for the amount of 
> > policy based discussion that has occurred of late - it is 
> > meant to be a technical working group.  Hence I honestly 
> > would like to see less soap-box speechs and more work towards 
> > a compromise, such as the one Janusz posted to the list.  
> > Although that idea got shot down, it
> > was the right kind of effort we should be concentrating on.     
> > 
> > 
> > Michael Young
> > 
> > -----Original Message-----
> > From: [e-mail] 
> [mailto:[e-mail]]
> > On Behalf Of Vittorio Bertola
> > Sent: January 17, 2003 5:03 AM
> > To: [e-mail]
> > Subject: An user's point of view on the privacy issue
> > 
> > 
> > Hello,
> > 
> > I am a newbie of this group and of the IETF WGs in general
> > (please pardon me for anything inappropriate I might 
> > unvoluntarily do). However, I have been discussing DNS 
> > privacy issues extensively in the last years, so please allow 
> > me to give my point of view on the ongoing privacy discussion.
> > 
> > Not addressing the privacy issue in the base protocol would
> > likely imply that the service would often be deployed in real 
> > life without any means to achieve privacy protection. 
> > Unfortunately, the present lack of privacy protection in the 
> > WHOIS system is plainly illegal in many countries, and I 
> > don't think it's reasonable to think that this situation can 
> > go on for long without actual lawsuits starting to happen, 
> > both towards ccTLD and gTLD registries and registrars. 
> > 
> > In fact, as others have already pointed out, many registries
> > (especially European ccTLDs) have already started to allow 
> > opting out from WHOIS under certain conditions or for certain 
> > types of data, or even, have already been sued on this. 
> > Personally, I think that the present situation where gTLD 
> > registrants are required to make all their data public won't 
> > last long.
> > 
> > Thus, any new protocol being created in this field should be
> > able to support the ability to mark data as private - 
> > otherwise in the end it might be useless or even damaging. If 
> > this protocol doesn't implement any simple and standard way 
> > to specify reasonable privacy directives together with data, 
> > it is likely that many registrars and registries will be soon 
> > forced, by law, lawsuits, or public opinion pressure, to add 
> > their own (non-standard and non-interoperable) ones.
> > 
> > The protocol must allow customers to specify privacy
> > conditions with the highest possible granularity, because it 
> > must be able to support policies that will be very different 
> > one from the other and will vary often (much more often than 
> > the protocol itself) according to non-technical decisions. No 
> > privacy policy should be hard-wired in the protocol (and this 
> > includes the policy of "no privacy is possible" that would 
> > result from the lack of privacy specification tools in the 
> > base protocol).
> > 
> > I must also point out that, according for example to the
> > European law, it is the customer, nor the registrar nor the 
> > registry nor any policy or standard making body, that decides 
> > what should be published and what should not. The registrar 
> > or registry are not allowed to alter the customer's 
> > indications on privacy. At most, the registrar/registry may 
> > refuse to supply the service if the customer does not accept 
> > to distribute data that are strictly necessary for the 
> > service to work. (It seems to me very doubtful that 
> > publishing my name and e-mail to the whole world is strictly 
> > necessary for my name servers to work. But this is a policy 
> > and legal discussion anyway, and is out of this list's
> > scope.)
> > 
> > So, the minimum level of granularity that the protocol should
> > support to be applicable in real life is the ability to mark 
> > each field of each domain name registration form as private 
> > or public, singularly for each (domain, field) couple.
> > 
> > The EU law also states that the owner of the data has the
> > right to verify and update the data and retire the consensus 
> > to the distribution at any time. So the protocol should allow 
> > for updates not only of the data but of the privacy indications too.
> > 
> > Theoretically, a registrar could ask separate approvals to
> > the customer for different uses of the same data. In this 
> > case, a mechanism with more levels of privacy would be 
> > necessary. However, this is an option for the registrar, not 
> > a requirement, so this could be left to extensions. 
> > Similarly, a specific approval is required to export data 
> > outside of the European Union, so a mechanism to specify a 
> > list of countries to which data can(not) be exported could be 
> > of use, but this problem can be easily avoided by the 
> > registrar by asking for such consensus, so this could be left 
> > as a possible extension too.
> > 
> > Thus, summarizing, I support the idea that a mechanism to 
> specify (at
> > least) whether each single field of each single domain name
> > is meant to be public or private should be added to the base 
> > protocol, and its implementation should be mandatory.
> > -- 
> > vb.                  [Vittorio Bertola - vb [at] bertola.eu.org]<---
> > -------------------> http://bertola.eu.org/ <-----------------------
> > 
> > 
> 



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0HEju9p027784 for <[e-mail]>; Fri, 17 Jan 2003 15:45:56 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0HEjuGQ027783 for ietf-provreg-outgoing; Fri, 17 Jan 2003 15:45:56 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail8.megamailservers.com (mail8.megamailservers.com [216.251.36.18]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0HEjs9p027776 for <[e-mail]>; Fri, 17 Jan 2003 15:45:55 +0100 (MET)
Received: from rraderxp (dodgy.tucows.com [207.136.98.130]) by mail8.megamailservers.com (8.12.5/8.12.0.Beta10) with ESMTP id h0HEjeIf086764; Fri, 17 Jan 2003 09:45:41 -0500 (EST)
Reply-To: <[e-mail]>
From: "Ross Wm. Rader" <[e-mail]>
To: "'Michael Young'" <[e-mail]>, "'Vittorio Bertola'" <[e-mail]>, <[e-mail]>
Subject: RE: An user's point of view on the privacy issue
Date: Fri, 17 Jan 2003 09:45:40 -0500
Organization: Tucows Inc.
Message-ID: <000801c2be37$1c9d8840$f80b000a@rraderxp>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <002101c2be2f$299f95e0$c302010a@DUN435>
Sender: [e-mail]
Precedence: bulk

> would like to see less soap-box speechs and more work towards 

Agreed - *but* I don't expect that we'll see many as long as you're up
there. I don't know about the rest of you, but I do appreciate Vittorio
taking the time out to specify what his requirements for the mechanism
might be. Once the smart guys figure out where that should happen,
specifications such as his will most undoubtedly help you figure out how
to make "what it looks like" work.

I've dropped out of even lurking for the past few days, but suffice to
say that this is all moot if the question is still "who" as per Joe's
question of the 8th... And, at the risk of getting ahead of myself, I'm
also not sure that I've seen an answer to Andrew's question of the 9th
regarding what basic "privacy" actually is. From my standpoint, the
entire line of conjecture is a bit of a red herring - it may simplify
the discussion to look at this as a data ownership/entity
relationship/data rights management issue as opposed to the more charged
(and elusive) question of "privacy" - unless someone has a reasonable
definition of "privacy" that they haven't shared with us...



                       -rwr




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

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


 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Michael Young
> Sent: Friday, January 17, 2003 8:49 AM
> To: 'Vittorio Bertola'; [e-mail]
> Subject: RE: An user's point of view on the privacy issue
> 
> 
> Thank you for providing your opinion on privacy issues 
> Vittorio.  I think you'll find by reviewing the list that the 
> current debate in the provreg working group is not about 
> whether or not a privacy mechanism is desirable, but really 
> about the technical implementation and where that should 
> happen.  There are multiple approaches to how to solve for 
> this problem, and all of them have their perceived advantages 
> and disadvantages. Some approaches that are being heavily 
> advocated from non-technical stakeholders have some serious 
> implementation and performance impacts, and that's really 
> whats at the heart of the debate right now.  BTW in my 
> opinion, this forum is not meant as a venue for the amount of 
> policy based discussion that has occurred of late - it is 
> meant to be a technical working group.  Hence I honestly 
> would like to see less soap-box speechs and more work towards 
> a compromise, such as the one Janusz posted to the list.  
> Although that idea got shot down, it
> was the right kind of effort we should be concentrating on.     
> 
> 
> Michael Young 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Vittorio Bertola
> Sent: January 17, 2003 5:03 AM
> To: [e-mail]
> Subject: An user's point of view on the privacy issue
> 
> 
> Hello,
> 
> I am a newbie of this group and of the IETF WGs in general 
> (please pardon me for anything inappropriate I might 
> unvoluntarily do). However, I have been discussing DNS 
> privacy issues extensively in the last years, so please allow 
> me to give my point of view on the ongoing privacy discussion.
> 
> Not addressing the privacy issue in the base protocol would 
> likely imply that the service would often be deployed in real 
> life without any means to achieve privacy protection. 
> Unfortunately, the present lack of privacy protection in the 
> WHOIS system is plainly illegal in many countries, and I 
> don't think it's reasonable to think that this situation can 
> go on for long without actual lawsuits starting to happen, 
> both towards ccTLD and gTLD registries and registrars. 
> 
> In fact, as others have already pointed out, many registries 
> (especially European ccTLDs) have already started to allow 
> opting out from WHOIS under certain conditions or for certain 
> types of data, or even, have already been sued on this. 
> Personally, I think that the present situation where gTLD 
> registrants are required to make all their data public won't 
> last long.
> 
> Thus, any new protocol being created in this field should be 
> able to support the ability to mark data as private - 
> otherwise in the end it might be useless or even damaging. If 
> this protocol doesn't implement any simple and standard way 
> to specify reasonable privacy directives together with data, 
> it is likely that many registrars and registries will be soon 
> forced, by law, lawsuits, or public opinion pressure, to add 
> their own (non-standard and non-interoperable) ones.
> 
> The protocol must allow customers to specify privacy 
> conditions with the highest possible granularity, because it 
> must be able to support policies that will be very different 
> one from the other and will vary often (much more often than 
> the protocol itself) according to non-technical decisions. No 
> privacy policy should be hard-wired in the protocol (and this 
> includes the policy of "no privacy is possible" that would 
> result from the lack of privacy specification tools in the 
> base protocol).
> 
> I must also point out that, according for example to the 
> European law, it is the customer, nor the registrar nor the 
> registry nor any policy or standard making body, that decides 
> what should be published and what should not. The registrar 
> or registry are not allowed to alter the customer's 
> indications on privacy. At most, the registrar/registry may 
> refuse to supply the service if the customer does not accept 
> to distribute data that are strictly necessary for the 
> service to work. (It seems to me very doubtful that 
> publishing my name and e-mail to the whole world is strictly 
> necessary for my name servers to work. But this is a policy 
> and legal discussion anyway, and is out of this list's
> scope.)
> 
> So, the minimum level of granularity that the protocol should 
> support to be applicable in real life is the ability to mark 
> each field of each domain name registration form as private 
> or public, singularly for each (domain, field) couple.
> 
> The EU law also states that the owner of the data has the 
> right to verify and update the data and retire the consensus 
> to the distribution at any time. So the protocol should allow 
> for updates not only of the data but of the privacy indications too.
> 
> Theoretically, a registrar could ask separate approvals to 
> the customer for different uses of the same data. In this 
> case, a mechanism with more levels of privacy would be 
> necessary. However, this is an option for the registrar, not 
> a requirement, so this could be left to extensions. 
> Similarly, a specific approval is required to export data 
> outside of the European Union, so a mechanism to specify a 
> list of countries to which data can(not) be exported could be 
> of use, but this problem can be easily avoided by the 
> registrar by asking for such consensus, so this could be left 
> as a possible extension too.
> 
> Thus, summarizing, I support the idea that a mechanism to specify (at
> least) whether each single field of each single domain name 
> is meant to be public or private should be added to the base 
> protocol, and its implementation should be mandatory.
> -- 
> vb.                  [Vittorio Bertola - vb [at] bertola.eu.org]<---
> -------------------> http://bertola.eu.org/ <-----------------------
> 
> 



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0HDn59p027257 for <[e-mail]>; Fri, 17 Jan 2003 14:49:05 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0HDn5SV027256 for ietf-provreg-outgoing; Fri, 17 Jan 2003 14:49:05 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0HDn39p027251 for <[e-mail]>; Fri, 17 Jan 2003 14:49:04 +0100 (MET)
Received: from [10.1.2.195] (helo=DUN435) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 18ZWrm-0004pM-00; Fri, 17 Jan 2003 08:49:02 -0500
From: "Michael Young" <[e-mail]>
To: "'Vittorio Bertola'" <[e-mail]>, <[e-mail]>
Subject: RE: An user's point of view on the privacy issue
Date: Fri, 17 Jan 2003 08:48:49 -0500
Message-ID: <002101c2be2f$299f95e0$c302010a@DUN435>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Thank you for providing your opinion on privacy issues Vittorio.  I
think you'll find by reviewing the list that the current debate in the
provreg working group is not about whether or not a privacy mechanism is
desirable, but really about the technical implementation and where that
should happen.  There are multiple approaches to how to solve for this
problem, and all of them have their perceived advantages and
disadvantages. Some approaches that are being heavily advocated from
non-technical stakeholders have some serious implementation and
performance impacts, and that's really whats at the heart of the debate
right now.  BTW in my opinion, this forum is not meant as a venue for
the amount of policy based discussion that has occurred of late - it is
meant to be a technical working group.  Hence I honestly would like to
see less soap-box speechs and more work towards a compromise, such as
the one Janusz posted to the list.  Although that idea got shot down, it
was the right kind of effort we should be concentrating on.     


Michael Young 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Vittorio Bertola
Sent: January 17, 2003 5:03 AM
To: [e-mail]
Subject: An user's point of view on the privacy issue


Hello,

I am a newbie of this group and of the IETF WGs in general (please
pardon me for anything inappropriate I might unvoluntarily do). However,
I have been discussing DNS privacy issues extensively in the last years,
so please allow me to give my point of view on the ongoing privacy
discussion.

Not addressing the privacy issue in the base protocol would likely imply
that the service would often be deployed in real life without any means
to achieve privacy protection. Unfortunately, the present lack of
privacy protection in the WHOIS system is plainly illegal in many
countries, and I don't think it's reasonable to think that this
situation can go on for long without actual lawsuits starting to happen,
both towards ccTLD and gTLD registries and registrars. 

In fact, as others have already pointed out, many registries (especially
European ccTLDs) have already started to allow opting out from WHOIS
under certain conditions or for certain types of data, or even, have
already been sued on this. Personally, I think that the present
situation where gTLD registrants are required to make all their data
public won't last long.

Thus, any new protocol being created in this field should be able to
support the ability to mark data as private - otherwise in the end it
might be useless or even damaging. If this protocol doesn't implement
any simple and standard way to specify reasonable privacy directives
together with data, it is likely that many registrars and registries
will be soon forced, by law, lawsuits, or public opinion pressure, to
add their own (non-standard and non-interoperable) ones.

The protocol must allow customers to specify privacy conditions with the
highest possible granularity, because it must be able to support
policies that will be very different one from the other and will vary
often (much more often than the protocol itself) according to
non-technical decisions. No privacy policy should be hard-wired in the
protocol (and this includes the policy of "no privacy is possible" that
would result from the lack of privacy specification tools in the base
protocol).

I must also point out that, according for example to the European law,
it is the customer, nor the registrar nor the registry nor any policy or
standard making body, that decides what should be published and what
should not. The registrar or registry are not allowed to alter the
customer's indications on privacy. At most, the registrar/registry may
refuse to supply the service if the customer does not accept to
distribute data that are strictly necessary for the service to work. (It
seems to me very doubtful that publishing my name and e-mail to the
whole world is strictly necessary for my name servers to work. But this
is a policy and legal discussion anyway, and is out of this list's
scope.)

So, the minimum level of granularity that the protocol should support to
be applicable in real life is the ability to mark each field of each
domain name registration form as private or public, singularly for each
(domain, field) couple.

The EU law also states that the owner of the data has the right to
verify and update the data and retire the consensus to the distribution
at any time. So the protocol should allow for updates not only of the
data but of the privacy indications too.

Theoretically, a registrar could ask separate approvals to the customer
for different uses of the same data. In this case, a mechanism with more
levels of privacy would be necessary. However, this is an option for the
registrar, not a requirement, so this could be left to extensions.
Similarly, a specific approval is required to export data outside of the
European Union, so a mechanism to specify a list of countries to which
data can(not) be exported could be of use, but this problem can be
easily avoided by the registrar by asking for such consensus, so this
could be left as a possible extension too.

Thus, summarizing, I support the idea that a mechanism to specify (at
least) whether each single field of each single domain name is meant to
be public or private should be added to the base protocol, and its
implementation should be mandatory.
-- 
vb.                  [Vittorio Bertola - vb [at] bertola.eu.org]<---
-------------------> http://bertola.eu.org/ <-----------------------




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0HA2p9p025775 for <[e-mail]>; Fri, 17 Jan 2003 11:02:51 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0HA2piQ025774 for ietf-provreg-outgoing; Fri, 17 Jan 2003 11:02:51 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from lazzaro.bertola.eu.org (net-197-95.noicomnet.it [194.153.197.95]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id h0HA2n9p025769 for <[e-mail]>; Fri, 17 Jan 2003 11:02:50 +0100 (MET)
Received: (qmail 7620 invoked from network); 17 Jan 2003 10:08:47 -0000
Received: from unknown (HELO PIETRO) (10.0.1.2) by 0 with SMTP; 17 Jan 2003 10:08:47 -0000
From: Vittorio Bertola <[e-mail]>
To: [e-mail]
Subject: An user's point of view on the privacy issue
Date: Fri, 17 Jan 2003 11:03:26 +0100
Message-ID: <[e-mail]>
X-Mailer: Forte Agent 1.9/32.560
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h0HA2o9p025770
Sender: [e-mail]
Precedence: bulk

Hello,

I am a newbie of this group and of the IETF WGs in general (please
pardon me for anything inappropriate I might unvoluntarily do).
However, I have been discussing DNS privacy issues extensively in the
last years, so please allow me to give my point of view on the ongoing
privacy discussion.

Not addressing the privacy issue in the base protocol would likely
imply that the service would often be deployed in real life without
any means to achieve privacy protection. Unfortunately, the present
lack of privacy protection in the WHOIS system is plainly illegal in
many countries, and I don't think it's reasonable to think that this
situation can go on for long without actual lawsuits starting to
happen, both towards ccTLD and gTLD registries and registrars. 

In fact, as others have already pointed out, many registries
(especially European ccTLDs) have already started to allow opting out
from WHOIS under certain conditions or for certain types of data, or
even, have already been sued on this. Personally, I think that the
present situation where gTLD registrants are required to make all
their data public won't last long.

Thus, any new protocol being created in this field should be able to
support the ability to mark data as private - otherwise in the end it
might be useless or even damaging. If this protocol doesn't implement
any simple and standard way to specify reasonable privacy directives
together with data, it is likely that many registrars and registries
will be soon forced, by law, lawsuits, or public opinion pressure, to
add their own (non-standard and non-interoperable) ones.

The protocol must allow customers to specify privacy conditions with
the highest possible granularity, because it must be able to support
policies that will be very different one from the other and will vary
often (much more often than the protocol itself) according to
non-technical decisions. No privacy policy should be hard-wired in the
protocol (and this includes the policy of "no privacy is possible"
that would result from the lack of privacy specification tools in the
base protocol).

I must also point out that, according for example to the European law,
it is the customer, nor the registrar nor the registry nor any policy
or standard making body, that decides what should be published and
what should not. The registrar or registry are not allowed to alter
the customer's indications on privacy. At most, the registrar/registry
may refuse to supply the service if the customer does not accept to
distribute data that are strictly necessary for the service to work.
(It seems to me very doubtful that publishing my name and e-mail to
the whole world is strictly necessary for my name servers to work. But
this is a policy and legal discussion anyway, and is out of this
list's scope.)

So, the minimum level of granularity that the protocol should support
to be applicable in real life is the ability to mark each field of
each domain name registration form as private or public, singularly
for each (domain, field) couple.

The EU law also states that the owner of the data has the right to
verify and update the data and retire the consensus to the
distribution at any time. So the protocol should allow for updates not
only of the data but of the privacy indications too.

Theoretically, a registrar could ask separate approvals to the
customer for different uses of the same data. In this case, a
mechanism with more levels of privacy would be necessary. However,
this is an option for the registrar, not a requirement, so this could
be left to extensions. Similarly, a specific approval is required to
export data outside of the European Union, so a mechanism to specify a
list of countries to which data can(not) be exported could be of use,
but this problem can be easily avoided by the registrar by asking for
such consensus, so this could be left as a possible extension too.

Thus, summarizing, I support the idea that a mechanism to specify (at
least) whether each single field of each single domain name is meant
to be public or private should be added to the base protocol, and its
implementation should be mandatory.
-- 
vb.                  [Vittorio Bertola - vb [at] bertola.eu.org]<---
-------------------> http://bertola.eu.org/ <-----------------------



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0EFdE9p022200 for <[e-mail]>; Tue, 14 Jan 2003 16:39:14 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h0EFdEX6022199 for ietf-provreg-outgoing; Tue, 14 Jan 2003 16:39:14 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0EFdD9p022194 for <[e-mail]>; Tue, 14 Jan 2003 16:39:13 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id KAA12373; Tue, 14 Jan 2003 10:39:03 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <ZHNYG798>; Tue, 14 Jan 2003 10:38:05 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: 56th IETF WG/BOF Scheduling
Date: Tue, 14 Jan 2003 10:36:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> Another thing to consider...
> 
> >Subject: 56th IETF WG/BOF Scheduling
> >Date: Tue, 07 Jan 2003 10:54:00 -0500
> >
> >56th IETF in San Francisco, CA
> >Meeting Dates: March 16-21, 2003
> >
> >We will be taking scheduling requests for ALL Working Groups and BOFs
> >starting today.
> >The cut-off for requesting a slot is Tuesday, February 25 at 
> 17:00 ET.

If we try to schedule a meeting could we do it towards the end of the week,
maybe Thursday?  I have a conflict brewing at the start of the week, and no
it doesn't have anything to do with green beer...

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0AChe9p013041 for <[e-mail]>; Fri, 10 Jan 2003 13:43:40 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0ACheKp013040 for ietf-provreg-outgoing; Fri, 10 Jan 2003 13:43:40 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0AChY9p013033 for <[e-mail]>; Fri, 10 Jan 2003 13:43:35 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id h0AChMOG014769; Fri, 10 Jan 2003 13:43:23 +0100 (CET) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Joe Abley'" <[e-mail]>, "'Edward Lewis'" <[e-mail]>, [e-mail]
Subject: Re: privacy 
In-reply-to: Your message of Wed, 08 Jan 2003 12:47:24 -0500. <[e-mail]> 
Date: Fri, 10 Jan 2003 13:43:22 +0100
From: Jaap Akkerhuis <[e-mail]>
Sender: [e-mail]
Precedence: bulk

    
    If I remember correctly, Jaap did say somewhere on the list that the
    proposal could work for .nl...
    

As promised, here follows the story of of it could work.

Disclaimer 1: I describe here the future situation (starting 29
January 2003) when our new Rules and Regulation go in effect.

Disclaimer 2: We are currently not using EPP for registrations, up
to now this is just an exercise in how we would deal with it.
Therefore, this description is likely incomplete.

Registry Model

For the purpose of this discussion, the .nl registry follows the
``thick'' model. That means, we keep a database witch all the
information necessary for registration domain names. From this
database we publish a subset in the whois server and, of course,
in the .nl name server.

Privacy policy

Some details about The dutch Personal Data Protection Act (as far
as I know, I'm not a lawyer, and as far relevant to this discussion).
Although in the law there is a part which tell you what kind of
things you are never supposed to disclose, such as social security
numbers, medical information, the usual stuff, there isn't really
anywhere detailed what is allowed and what isn't.

For personal data, each database holder is required to have a data
policy. That must state which data is collected, the purpose and
use of the data collected, how data might be collected and which
data is published in relation to with the purpose. It must be
possible to suppress some of the Personal data published when the
interest of the Person to withhold the data is higher the standard
disclosure process. So it is actually a balancing act and is depending
on the interests and within relation to the Person whether or not
this opt-out is granted.

Some studies have been conducted how this related the domain name
registration, discussions with the privacy authorities etc. (These
reports are on line in case someone wants to read them).  This
resulted in the end in the a policy document, published at
http://www.domain-registry.nl/sidn_english/flat/General/Rules/New_regulations/New_SIDN_regulations_pursuant_to_the_Personal_Data_Protection_Act/index.html

Among other things it states

Article 2 Purpose

 2.1 The purposes of Processing are:

     a. the processing of Applications for Domain Names and Personal
     Domain Names and all associated and resulting activities;

     b. the consideration of requests and complaints submitted by
     Holders of a Domain Name and Data Subjects;

     c. the provision of data to Participants(*) to facilitate their
     work;

     d. the inclusion of the data in the zone file;

     e. the inclusion, in addition to the above purposes, in the
     public section of the Register as referred to in Article 23.2
     of the Regulations for the Registration of .nl Domain Names
     of the data specified in Annex I for the purpose of:

	- solving any technical problems regarding the operation
	of the Internet;

	- Applications for Registration of (free) Domain Names;

	- the protection of intellectual property rights;

	- the prevention and combating of illegal and harmful content
	on the Internet.

(*) Participant == registrar

Note also that all this policy stuff is actually enforced by the
contracts between the registry, registrars and registrants.

In the Annex you 'll find:

Annex I Publicly accessible data

Domain Name/Personal Domain Name
Date of registration
Name and address of Holder of the Domain Name
Status of the domain (active, blocked, free)
Name, telephone number and e-mail address of the Holders administrative
	contact person
Name, telephone number and e-mail address of one or more technical
	contact persons
Master and slave Nameserver names and IP numbers


So these are the things that will be disclosed and in EPP the
disclosure attribute should have this as default value in the
registration request.  The request will processed and the name
registered if there aren't other problems.

If you put opt-out (non-Disclose) attributes to these, a different
process is followed, the balancing of interest need to take place.

Sometimes this is obvious. For some of the data elements the opt-out
will cause a straightforward denial of the request. We consider the
main purpose of a domain name registry to p[publish information in
the DNS, so, if you don't want to disclose these things, there is
no point for a registration at all. Also, there are case where the
opt-out is granted directly (see the policy document), so then the
request will follow the standard registration process and the opt-out
will happen.

However, when it when the opt-out request requires really to be
judged, the request is put in the pending state and put into a
separate queue. Then the process of the opt-out will take place.
If the outcome of that is something that the requester doesn't agree
which, he/she can actually appeal to an appeal committee
(which is independent from the registry). Depending on all of this,
the request for opt-out might be ignored or granted. In any case,
this is all outside the EPP protocol.

So yes, the non-disclose attribute will work for us without any
problem. It is possible that we might do extensions to aid with the
balancing of interest process if we get experience about this.
However, since policies change much quicker and easier due to changes
of laws etc. then protocols, it is unlikely that we do that.

The upshot of this is that all the attribute doesn't define a privacy
policy in anyway. That is done with the contracts, rules & regulations.
The attribute just makes it possible to automate the process somewhat.

A registrar dealing with multiple registries with different policies
should have set different defaults for these registries in the
application that generates the EPP. For the .se these defaults, for
the .nl others. I think that these defaults is not something which
should be in the specifications. Of course, you might want some
default in case it isn't specified. In that case, Disclose, is the
most practical.

	jaap



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09Ju39p005379 for <[e-mail]>; Thu, 9 Jan 2003 20:56:03 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h09Ju3Vg005378 for ietf-provreg-outgoing; Thu, 9 Jan 2003 20:56:03 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09Ju19p005372 for <[e-mail]>; Thu, 9 Jan 2003 20:56:01 +0100 (MET)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h09Jv7R5000989; Thu, 9 Jan 2003 14:57:07 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Randy Bush <[e-mail]>
cc: Joe Abley <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: privacy 
In-Reply-To: Your message of "Thu, 09 Jan 2003 04:38:08 PST." <[e-mail]> 
Date: Thu, 09 Jan 2003 14:57:07 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> >> in idle moments, i am trying to understand the mechanisms and
> >> poilicy useful/needed by a swedish registrant, using a registrar
> >> located in brasil, to register in a domain which has its registry
> >> in say american or new zealand juristiction.  and, of course, the
> >> registrant has personal preferences, "don't publish my fax number."
> > Does it seem that a simple, boolean "do not disclose" flag on each 
> > field is sufficient to accommodate the privacy requirements of that 
> > scenario?
> 
> one can always imagine more complex scenarios.  but the
> per-attribute dnp approach seems to be one of those which covers
> the important cases, certainly the current ones, with a simple
> mechanism.  it's like one of those 90% solutions with 10% of the
> cost.

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

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

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

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

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

Again, its a small matter.

Eric

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09Il29p004555 for <[e-mail]>; Thu, 9 Jan 2003 19:47:02 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h09Il2SS004554 for ietf-provreg-outgoing; Thu, 9 Jan 2003 19:47:02 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from p2.cavebear.com (p2.cavebear.com [199.184.128.35]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09Il09p004549 for <[e-mail]>; Thu, 9 Jan 2003 19:47:00 +0100 (MET)
Received: from npax.cavebear.com (npax.cavebear.com [192.203.17.71]) by p2.cavebear.com (8.12.5/8.11.6) with SMTP id h09IkwCo001773 for <[e-mail]>; Thu, 9 Jan 2003 10:46:59 -0800
Received: from npax.cavebear.com (localhost.localdomain [127.0.0.1]) by npax.cavebear.com (8.12.5/8.11.6) with ESMTP id h09IkwSS003299 for <[e-mail]>; Thu, 9 Jan 2003 10:46:58 -0800
Date: Thu, 9 Jan 2003 10:46:57 -0800 (PST)
Reply-To: Karl Auerbach <[e-mail]>
To: [e-mail], Rick Wesson <[e-mail]>, <[e-mail]>
cc: Richard Shockey <[e-mail]>, Stephane Bortzmeyer <[e-mail]>, Edward Lewis <[e-mail]>
Subject: Re: privacy
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
From: Karl Auerbach <[e-mail]>
X-Delivery-Agent: TMDA/0.65 (Johnstown)
Sender: [e-mail]
Precedence: bulk

On Wed, 8 Jan 2003, Randy Bush wrote:

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

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

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

Thus the privacy policies had to express limitions of combinations.

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

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

		--karl--





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09ISZ9p004361 for <[e-mail]>; Thu, 9 Jan 2003 19:28:35 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h09ISZxr004360 for ietf-provreg-outgoing; Thu, 9 Jan 2003 19:28:35 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09ISY9p004355 for <[e-mail]>; Thu, 9 Jan 2003 19:28:34 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id NAA21143; Thu, 9 Jan 2003 13:28:25 -0500 (EST)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <ZHNV1QV1>; Thu, 9 Jan 2003 13:26:24 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: document management
Date: Thu, 9 Jan 2003 13:26:24 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> But that is not the only issue out there.  There is the ROID issue 
> waiting along with some others that we really ought to solve before 
> we can leave the PS orbit.  (I.e., if we hit PS soon, we'll have to 
> do it again anyway to handle some of the potential changes.)
> 
> I'm proposing that we withdraw the current document set from the IESG 
> review cycle, address all of the IESG comments anyway and then move 
> on to addressing the other latent issues and resubmit for PS as soon 
> as we can.  Perhaps in February.
> 
> Comments?

I'm not convinced that the ROID issue is accepted as an issue by the WG.  It
was discussed to death in the past, and one person recently brought it up as
a concern.  I'd like to confirm that people really think it's something to
pull back for.  I don't think it is, especially since it was the topic of
extensive discussion in the past and the current documents reflect the
outcome of those discussions.

Note that I'm not a ROID advocate, and I'd have no regrets if we did decide
to remove them at some point in the future if extended implementation
experience demonstrates that they shouldn't be included.

In short: I'd like to get the IESG privacy comment debate settled and get
the documents moving again.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09IH09p004209 for <[e-mail]>; Thu, 9 Jan 2003 19:17:00 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h09IGxsJ004206 for ietf-provreg-outgoing; Thu, 9 Jan 2003 19:16:59 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09IGu9p004200 for <[e-mail]>; Thu, 9 Jan 2003 19:16:57 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h09IGrYm096494; Thu, 9 Jan 2003 13:16:53 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA02691; Thu, 9 Jan 2003 13:16:52 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0dba436ca654e5@[192.149.252.226]>
Date: Thu, 9 Jan 2003 13:16:21 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: Fwd: 56th IETF WG/BOF Scheduling
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Another thing to consider...

>Subject: 56th IETF WG/BOF Scheduling
>Date: Tue, 07 Jan 2003 10:54:00 -0500
>
>56th IETF in San Francisco, CA
>Meeting Dates: March 16-21, 2003
>
>We will be taking scheduling requests for ALL Working Groups and BOFs
>starting today.
>The cut-off for requesting a slot is Tuesday, February 25 at 17:00 ET.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09Hs49p004000 for <[e-mail]>; Thu, 9 Jan 2003 18:54:04 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h09Hs47j003999 for ietf-provreg-outgoing; Thu, 9 Jan 2003 18:54:04 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09Hs29p003994 for <[e-mail]>; Thu, 9 Jan 2003 18:54:03 +0100 (MET)
Received: from andrew by mail.libertyrms.com with local (Exim 3.22 #3 (Debian)) id 18WgsU-0000IA-00 for <[e-mail]>; Thu, 09 Jan 2003 12:54:02 -0500
Date: Thu, 9 Jan 2003 12:54:02 -0500
From: Andrew Sullivan <[e-mail]>
To: [e-mail]
Subject: Re: privacy
Message-ID: <[e-mail]>
Mail-Followup-To: Andrew Sullivan <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Jan 08, 2003 at 07:37:02PM -0800
Sender: [e-mail]
Precedence: bulk

On Wed, Jan 08, 2003 at 07:37:02PM -0800, Allison Mankin wrote:
> Rick,
> 
> We are just trying ensure that a basic privacy can be implemented
> on the fields.  

I get the impression, from reading the thread, that it is not clear
what "a basic privacy" is.  But any time I try to answer that
question, I always end up thinking about policy matters and not
technical ones.  That seems to me to be a reason to believe that this
problem should not be addressed in the base specification.

> There are a number of other efforts on privacy in IETF working groups
> and at large - this is not the only place nor the only way that a group
> has been asked to make mandatory-to-implement privacy.  Geopriv is an

And so what if the others come up with a mandatory-to-implement
privacy that is inconsistent with the mandatory-to-implement privacy
that ends up in the EPP specification?  It seems to me it might be a
mistake to implement privacy piecemeal.

(As is the tradition in the IETF, I speak only for myself and not my
employer.  My employer might well not agree with my view.)

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Liberty RMS                           Toronto, Ontario Canada
<[e-mail]>                              M2P 2A8
                                         [phone] x110



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09Ftk9p002931 for <[e-mail]>; Thu, 9 Jan 2003 16:55:46 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h09Ftj2C002930 for ietf-provreg-outgoing; Thu, 9 Jan 2003 16:55:45 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09Fth9p002925 for <[e-mail]>; Thu, 9 Jan 2003 16:55:43 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h09FthYm090070; Thu, 9 Jan 2003 10:55:43 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA15944; Thu, 9 Jan 2003 10:55:42 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b06ba434aafbd3c@[192.149.252.226]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 9 Jan 2003 10:55:37 -0500
To: Eric Brunner-Williams in Portland Maine <[e-mail]>, Edward Lewis <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: document management
Cc: [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Some background reading:

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

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

In the last, item #5 lists the three issues of which I'm aware.

The minutes of the last face-2-face:

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

The open issues are mentioned in there...

At 10:48 -0500 1/9/03, Eric Brunner-Williams in Portland Maine wrote:
>>  But that is not the only issue out there.  There is the ROID issue
>>  waiting along with some others that we really ought to solve before
>>  we can leave the PS orbit.  (I.e., if we hit PS soon, we'll have to
>>  do it again anyway to handle some of the potential changes.)
>
>Would you, or the document editor(s), do me the kindness of restating the
>open issues?
>
>TiA,
>Eric

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09FlW9p002863 for <[e-mail]>; Thu, 9 Jan 2003 16:47:32 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h09FlWZF002862 for ietf-provreg-outgoing; Thu, 9 Jan 2003 16:47:32 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09FlU9p002857 for <[e-mail]>; Thu, 9 Jan 2003 16:47:30 +0100 (MET)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h09FmbR5000510; Thu, 9 Jan 2003 10:48:37 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: [e-mail], [e-mail], [e-mail]
Subject: Re: document management 
In-Reply-To: Your message of "Thu, 09 Jan 2003 10:06:57 EST." <a05111b03ba433f320bd5@[192.149.252.226]> 
Date: Thu, 09 Jan 2003 10:48:37 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> But that is not the only issue out there.  There is the ROID issue 
> waiting along with some others that we really ought to solve before 
> we can leave the PS orbit.  (I.e., if we hit PS soon, we'll have to 
> do it again anyway to handle some of the potential changes.)

Would you, or the document editor(s), do me the kindness of restating the
open issues?

TiA,
Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09F7A9p002503 for <[e-mail]>; Thu, 9 Jan 2003 16:07:10 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h09F7AP5002502 for ietf-provreg-outgoing; Thu, 9 Jan 2003 16:07:10 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09F779p002497 for <[e-mail]>; Thu, 9 Jan 2003 16:07:07 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h09F76Ym087986; Thu, 9 Jan 2003 10:07:06 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA01997; Thu, 9 Jan 2003 10:07:05 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b03ba433f320bd5@[192.149.252.226]>
Date: Thu, 9 Jan 2003 10:06:57 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: document management
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

I have a question to float to the group that is not privacy related.

Currently we have a set of documents sitting in the IESG review 
process, which is why we are covering the privacy issue rather 
intensively right now.  Procedurally, if and when we address this, 
the documents could continue onward to a Proposed Standard RFC set.

We have been having difficulty getting consensus on the privacy issue.

But that is not the only issue out there.  There is the ROID issue 
waiting along with some others that we really ought to solve before 
we can leave the PS orbit.  (I.e., if we hit PS soon, we'll have to 
do it again anyway to handle some of the potential changes.)

I'm proposing that we withdraw the current document set from the IESG 
review cycle, address all of the IESG comments anyway and then move 
on to addressing the other latent issues and resubmit for PS as soon 
as we can.  Perhaps in February.

Comments?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09Clm9p001399 for <[e-mail]>; Thu, 9 Jan 2003 13:47:48 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h09ClmLH001398 for ietf-provreg-outgoing; Thu, 9 Jan 2003 13:47:48 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09Cll9p001393 for <[e-mail]>; Thu, 9 Jan 2003 13:47:47 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id h09ClhOG009590 for <[e-mail]>; Thu, 9 Jan 2003 13:47:43 +0100 (CET) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id h09ClgOL009589 for [e-mail]; Thu, 9 Jan 2003 13:47:42 +0100 (CET)
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09Cc89p001353 for <[e-mail]>; Thu, 9 Jan 2003 13:38:09 +0100 (MET)
Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18Wbwm-000Pdp-00; Thu, 09 Jan 2003 04:38:08 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Joe Abley <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: privacy
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 09 Jan 2003 04:38:08 -0800
Sender: [e-mail]
Precedence: bulk

>> in idle moments, i am trying to understand the mechanisms and
>> poilicy useful/needed by a swedish registrant, using a registrar
>> located in brasil, to register in a domain which has its registry
>> in say american or new zealand juristiction.  and, of course, the
>> registrant has personal preferences, "don't publish my fax number."
> Does it seem that a simple, boolean "do not disclose" flag on each 
> field is sufficient to accommodate the privacy requirements of that 
> scenario?

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

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

randy



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09CVt9p001320 for <[e-mail]>; Thu, 9 Jan 2003 13:31:55 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h09CVt81001319 for ietf-provreg-outgoing; Thu, 9 Jan 2003 13:31:55 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from felix.automagic.org (felix.automagic.org [204.152.186.101]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id h09CVr9p001312 for <[e-mail]>; Thu, 9 Jan 2003 13:31:54 +0100 (MET)
Received: (qmail 4690 invoked by uid 0); 9 Jan 2003 12:31:50 -0000
Received: from localhost.automagic.org (HELO isc.org) (127.0.0.1) by localhost.automagic.org with SMTP; 9 Jan 2003 12:31:50 -0000
Date: Thu, 9 Jan 2003 07:32:41 -0500
Subject: Re: privacy
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: "Paul M. Kane" <[e-mail]>, [e-mail], [e-mail]
To: Randy Bush <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: [e-mail]
Precedence: bulk

On Thursday, Jan 9, 2003, at 06:43 Canada/Eastern, Randy Bush wrote:

>> IMHO the spec should contain the basic parameters then each registry 
>> can
>>   extend to accomodate the applicable policy 
>> (_laws_of_the_jurisdiction)
>> ..... which probably means that Registars, if they want to trade in 
>> the
>> jurisdiciton will have to adjust their interfaces (C2Rr and Rr2Ry)
>> accordingly.
>> The effect will be that gTLD Registries (as ccTLD registries have to 
>> do
>> already) must respect national operating conditions if they want
>> customers from that nation.... but such is politics not technology
>
> in idle moments, i am trying to understand the mechanisms and
> poilicy useful/needed by a swedish registrant, using a registrar
> located in brasil, to register in a domain which has its registry
> in say american or new zealand juristiction.  and, of course, the
> registrant has personal preferences, "don't publish my fax number."

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

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

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


Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09CDD9p001172 for <[e-mail]>; Thu, 9 Jan 2003 13:13:13 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h09CDDLG001171 for ietf-provreg-outgoing; Thu, 9 Jan 2003 13:13:13 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09CDC9p001166 for <[e-mail]>; Thu, 9 Jan 2003 13:13:13 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id h09CDCOG009481 for <[e-mail]>; Thu, 9 Jan 2003 13:13:12 +0100 (CET) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id h09CDChb009480 for [e-mail]; Thu, 9 Jan 2003 13:13:12 +0100 (CET)
Received: from mail.nrm.se (mail.nrm.se [193.10.36.5]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09C719p001118 for <[e-mail]>; Thu, 9 Jan 2003 13:07:01 +0100 (MET)
Received: from pop.nrm.se (pop.nrm.se [193.10.57.9]) by mail.nrm.se (8.10.0/8.10.0) with ESMTP id h09C6ON25043; Thu, 9 Jan 2003 13:06:24 +0100
Date: Thu, 9 Jan 2003 13:06:26 +0100 (CET)
From: =?iso-8859-1?Q?Eva_Steng=E5rd?= <[e-mail]>
To: Randy Bush <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>
Subject: Re: privacy
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Sender: [e-mail]
Precedence: bulk

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

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

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

Hope this can be of some help,

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

On Wed, 8 Jan 2003, Randy Bush wrote:

> > Excellent point, I could not agree more ... IMHO all of this goes to the
> > much larger issue of privacy policy across all IETF protocols
> 
> nope.  to repeat yet again.  we are not discussing privacy *policy*.
> we are discussing a mechanism by which a wide set of policies may
> be implemented.  operating system theory 101.
> 
> randy
> 





Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09C9F9p001149 for <[e-mail]>; Thu, 9 Jan 2003 13:09:15 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h09C9F9q001148 for ietf-provreg-outgoing; Thu, 9 Jan 2003 13:09:15 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09C9D9p001143 for <[e-mail]>; Thu, 9 Jan 2003 13:09:14 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id h09C9AOG009457 for <[e-mail]>; Thu, 9 Jan 2003 13:09:10 +0100 (CET) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id h09C9A7A009456 for [e-mail]; Thu, 9 Jan 2003 13:09:10 +0100 (CET)
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09BhW9p000884 for <[e-mail]>; Thu, 9 Jan 2003 12:43:32 +0100 (MET)
Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18Wb5k-000POh-00; Thu, 09 Jan 2003 03:43:20 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Paul M. Kane" <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: privacy
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 09 Jan 2003 03:43:20 -0800
Sender: [e-mail]
Precedence: bulk

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

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

randy



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09BCw9p000691 for <[e-mail]>; Thu, 9 Jan 2003 12:12:58 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h09BCw2J000690 for ietf-provreg-outgoing; Thu, 9 Jan 2003 12:12:58 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09BCu9p000685 for <[e-mail]>; Thu, 9 Jan 2003 12:12:56 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id h09BCqOG009319; Thu, 9 Jan 2003 12:12:53 +0100 (CET) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: "Hollenbeck, Scott" <[e-mail]>
cc: "'Edward Lewis'" <[e-mail]>, [e-mail]
Subject: Re: privacy 
In-reply-to: Your message of Wed, 08 Jan 2003 12:47:24 -0500. <[e-mail]> 
Date: Thu, 09 Jan 2003 12:12:52 +0100
From: Jaap Akkerhuis <[e-mail]>
Sender: [e-mail]
Precedence: bulk

    
    If I remember correctly, Jaap did say somewhere on the list that the
    proposal could work for .nl...
    
I'll try to give a (lengthy) description later today. It takes some
time to prepare because I have to tocuh on our local operational/privacy
issues and I have silly meetings as well to attend, so that's why
it might take some time.

	jaap


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09AIn9p000371 for <[e-mail]>; Thu, 9 Jan 2003 11:18:49 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h09AInPg000366 for ietf-provreg-outgoing; Thu, 9 Jan 2003 11:18:49 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09AIm9p000361 for <[e-mail]>; Thu, 9 Jan 2003 11:18:48 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id h09AImOG008948 for <[e-mail]>; Thu, 9 Jan 2003 11:18:48 +0100 (CET) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id h09AIm0O008947 for [e-mail]; Thu, 9 Jan 2003 11:18:48 +0100 (CET)
Received: from psg.com (psg.com [147.28.0.62]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h093b99p027862 for <[e-mail]>; Thu, 9 Jan 2003 04:37:09 +0100 (MET)
Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 3.36 #2) id 18WTV8-000N0Q-00; Wed, 08 Jan 2003 19:37:02 -0800
To: Rick Wesson <[e-mail]>
cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>, Edward Lewis <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: privacy 
In-Reply-To: Message from Rick Wesson <[e-mail]>  of "Wed, 08 Jan 2003 09:35:27 PST." <[e-mail]> 
Date: Wed, 08 Jan 2003 19:37:02 -0800
From: Allison Mankin <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Rick,

We are just trying ensure that a basic privacy can be implemented
on the fields.  Like what we have done for years in IETF with
security: mandatory-to-implement baseline, with the customized stuff
in extensions.

There are a number of other efforts on privacy in IETF working groups
and at large - this is not the only place nor the only way that a group
has been asked to make mandatory-to-implement privacy.  Geopriv is an
entire working group for that.   I know, as its co-chair, how hard
the problem is.

Allison

> 
> Patrik,
> 
> > What IESG want is _some_ mandatory to implement mechanism which makes
> > it possible for the registrar to say to the registry "Do not disclose
> > this attribute to a third party". If the wg want to have the mandatory
> > to implement mechanism more powerful than that, fine. What is not ok is
> > the protocol not having any mandatory to implement privacy mechanism in
> > it, only extensions.
> 
> The issue that some folks have with and IESG mandatory to implement
> privacy capability in the prov-reg domain registration context is that
> addressing privacy just in epp is not a solution. Addressing privacy in
> epp also requires addressing it in the publishing protocols.
> 
> privacy is a thick issues and I've not seen/herd one prov-reg participant
> stand up and say "we understand privacy and here is what should happen"
> What we do see on the list and in the meetings is that we are not the
> people who should develop a privacy context and we don't know how to do
> it.
> 
> we have asked for additional direction and get a responses that are obtuse
> and confusing. Everyone appears to agree that privacy is a more complex
> issue than the IESG is willing to accept and that provreg may not be the
> place to define such capabilities.
> 
> I request that you consider that this working group may not be capable of
> addressing the problem and appreciate your thoughts on the next step if
> this proves to be true.
> 
> -rick
> 
> 



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09AIP9p000351 for <[e-mail]>; Thu, 9 Jan 2003 11:18:25 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h09AIPFj000350 for ietf-provreg-outgoing; Thu, 9 Jan 2003 11:18:25 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09AIO9p000345 for <[e-mail]>; Thu, 9 Jan 2003 11:18:24 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id h09AINOG008939 for <[e-mail]>; Thu, 9 Jan 2003 11:18:23 +0100 (CET) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id h09AINTw008938 for [e-mail]; Thu, 9 Jan 2003 11:18:23 +0100 (CET)
Received: from psg.com (psg.com [147.28.0.62]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h093Mu9p027801 for <[e-mail]>; Thu, 9 Jan 2003 04:22:56 +0100 (MET)
Received: from localhost ([127.0.0.1] helo=psg.com ident=mankin) by psg.com with esmtp (Exim 3.36 #2) id 18WTHP-000MT8-00; Wed, 08 Jan 2003 19:22:51 -0800
To: Rick Wesson <[e-mail]>
cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>, Edward Lewis <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: privacy 
In-Reply-To: Message from Rick Wesson <[e-mail]>  of "Wed, 08 Jan 2003 09:35:27 PST." <[e-mail]> 
Date: Wed, 08 Jan 2003 19:22:36 -0800
From: Allison Mankin <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Rick,




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09A2t9p000192 for <[e-mail]>; Thu, 9 Jan 2003 11:02:55 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h09A2tB6000191 for ietf-provreg-outgoing; Thu, 9 Jan 2003 11:02:55 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09A2s9p000185 for <[e-mail]>; Thu, 9 Jan 2003 11:02:54 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id h09A2rOG008736 for <[e-mail]>; Thu, 9 Jan 2003 11:02:53 +0100 (CET) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id h09A2r2J008735 for [e-mail]; Thu, 9 Jan 2003 11:02:53 +0100 (CET)
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08LFN9p024706 for <[e-mail]>; Wed, 8 Jan 2003 22:15:23 +0100 (MET)
Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18WNXm-000MWz-00; Wed, 08 Jan 2003 13:15:22 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Rick Wesson <[e-mail]>
Cc: Richard Shockey <[e-mail]>, Stephane Bortzmeyer <[e-mail]>, Edward Lewis <[e-mail]>, "'[e-mail]'" <[e-mail]>, <[e-mail]>
Subject: Re: privacy
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 08 Jan 2003 13:15:22 -0800
Sender: [e-mail]
Precedence: bulk

>> nope.  to repeat yet again.  we are not discussing privacy *policy*.
>> we are discussing a mechanism by which a wide set of policies may
>> be implemented.  operating system theory 101.
>
> maybe we had different instructors... to discuss capabilities of
> implementing a policy we must understand the range of policies
> and that is clearly out of scope for this group.

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

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

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

randy



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09A2d9p000183 for <[e-mail]>; Thu, 9 Jan 2003 11:02:39 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h09A2d2c000182 for ietf-provreg-outgoing; Thu, 9 Jan 2003 11:02:39 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h09A2d9p000177 for <[e-mail]>; Thu, 9 Jan 2003 11:02:39 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id h09A2cOG008728 for <[e-mail]>; Thu, 9 Jan 2003 11:02:38 +0100 (CET) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id h09A2bkx008727 for [e-mail]; Thu, 9 Jan 2003 11:02:38 +0100 (CET)
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08Kex9p024225 for <[e-mail]>; Wed, 8 Jan 2003 21:41:00 +0100 (MET)
Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18WN0R-000MKf-00; Wed, 08 Jan 2003 12:40:56 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Richard Shockey <[e-mail]>
Cc: Stephane Bortzmeyer <[e-mail]>, Rick Wesson <[e-mail]>, Edward Lewis <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: privacy
References: <[e-mail]> <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 08 Jan 2003 12:40:56 -0800
Sender: [e-mail]
Precedence: bulk

> Excellent point, I could not agree more ... IMHO all of this goes to the
> much larger issue of privacy policy across all IETF protocols

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

randy



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h099sj9p000144 for <[e-mail]>; Thu, 9 Jan 2003 10:54:45 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h099sjtl000143 for ietf-provreg-outgoing; Thu, 9 Jan 2003 10:54:45 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h099si9p000138 for <[e-mail]>; Thu, 9 Jan 2003 10:54:44 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id h099sdOG008655; Thu, 9 Jan 2003 10:54:40 +0100 (CET) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: [e-mail]
Subject: Re: mail list traffic 
In-reply-to: Your message of Wed, 08 Jan 2003 13:51:58 -0500. <a05111b0fba4220af5942@[192.149.252.226]> 
Date: Thu, 09 Jan 2003 10:54:39 +0100
From: Jaap Akkerhuis <[e-mail]>
Sender: [e-mail]
Precedence: bulk

    Pertinent to the discussion on privacy, I fear that our list's
    spam protection is halting some messages.  Randy has sent an
    answer to the privacy topic that has not appeared on the mailing
    list.  (It just dawned on me why.)  I think one from Richard
    Shockey shares the same fate.

Yes, two messages were waiting approval (from Randy & Richard) and
I approved them immediately when I noticed them.

    I don't have the keys to the mail list management software (if
    they've been given to me, I've lost them), so I need to ask
    Jaap (or whoever else is at the controls) if (t)he(y) could
    look through the held messages and approve any on the topic.

The server itself is in Sweden, I only have the mojordomo controls.
I'll send them in a seperate mail.

    I'm putting this out publicly just to let folks know that there's
    an effort to get the public discussion going from all angles,
    we're just suffering some technical difficulties.

I investigated this a bit and the answer is that there are no
technical difficulties.  Randy is not on the subscribtion list at
all and Richard uses multiple addresses. He is subscribed with his
.us address and used a .biz address for this contribution. Therefore,
the messages were waiting for approval.

	jaap



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h099AI9p029676 for <[e-mail]>; Thu, 9 Jan 2003 10:10:18 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h099AIFZ029675 for ietf-provreg-outgoing; Thu, 9 Jan 2003 10:10:18 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from mailer (mailer.io [194.205.62.101]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h099AG9p029661 for <[e-mail]>; Thu, 9 Jan 2003 10:10:17 +0100 (MET)
Received: from REACTO.com  by mailer (8.11.5/8.11.5) with ESMTP id h099FcC17185; Thu, 9 Jan 2003 09:15:38 GMT
Message-ID: <[e-mail]>
Date: Thu, 09 Jan 2003 09:10:36 +0000
From: "Paul M. Kane" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en, en-us
MIME-Version: 1.0
To: Randy Bush <[e-mail]>
CC: Rick Wesson <[e-mail]>, Edward Lewis <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: privacy
References: <[e-mail]>	<[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Well said Randy.......

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

Best

Paul

Randy Bush wrote:
>>would you please discuss your rationale in the light that all
>>gTLD registrations will also be published in the whois negating
>>any utility of your requirement.
> 
> 
> one - they won't be, as some registrants register from legal
> juristictions which have stronger privacy requirements.  please
> listen to what paf is trying to tell you.
> 
> two - i know this will come as a shock, but there are registries
> other than gtlds
> 
> three - there are more concerned parties here than registries.
> again, listen to paf
> 
> randy
> 
> 




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0997J9p029643 for <[e-mail]>; Thu, 9 Jan 2003 10:07:19 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h0997Iqn029642 for ietf-provreg-outgoing; Thu, 9 Jan 2003 10:07:18 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h0997C9p029634 for <[e-mail]>; Thu, 9 Jan 2003 10:07:12 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id h09979OG008483 for <[e-mail]>; Thu, 9 Jan 2003 10:07:09 +0100 (CET) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id h09979JZ008482 for [e-mail]; Thu, 9 Jan 2003 10:07:09 +0100 (CET)
Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08HpI9p022675 for <[e-mail]>; Wed, 8 Jan 2003 18:51:19 +0100 (MET)
Received: from rshockeybox.neustar.biz (stih650b-eth-s1p2c0.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id h08HoQZ17443; Wed, 8 Jan 2003 17:50:26 GMT
Message-Id: <[e-mail]>
X-Sender: 
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 08 Jan 2003 12:52:31 -0500
To: Stephane Bortzmeyer <[e-mail]>, Rick Wesson <[e-mail]>
From: Richard Shockey <[e-mail]>
Subject: Re: privacy
Cc: Randy Bush <[e-mail]>, Edward Lewis <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

At 05:50 PM 1/8/2003 +0100, Stephane Bortzmeyer wrote:
>On Wed, Jan 08, 2003 at 08:29:29AM -0800,
>  Rick Wesson <[e-mail]> wrote
>  a message of 32 lines which said:
>
> > IMHO, privacy needs to be addressed in a superset of the protocols (epp,
> > crisp, whois) and a specific group tasked with that job;
>
>This is very reasonable (sorry for the fine members of the Provreg
>group but last-minute attempts to solve a problem as large as the
>privacy policies in a few lines of patch to the I-D are quite
>laughable).

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

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

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

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

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


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


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


##########

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


Dear colleagues,

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

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

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

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

Best for a Happy New Year,

Danny Weitzner

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



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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h098ar9p029460 for <[e-mail]>; Thu, 9 Jan 2003 09:36:53 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h098ar3Z029459 for ietf-provreg-outgoing; Thu, 9 Jan 2003 09:36:53 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h098aq9p029454 for <[e-mail]>; Thu, 9 Jan 2003 09:36:53 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id h098amOG008305 for <[e-mail]>; Thu, 9 Jan 2003 09:36:48 +0100 (CET) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id h098am7f008304 for [e-mail]; Thu, 9 Jan 2003 09:36:48 +0100 (CET)
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08HN49p022331 for <[e-mail]>; Wed, 8 Jan 2003 18:23:04 +0100 (MET)
Received: from localhost ([127.0.0.1] helo=rip.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 18WJuw-000LUS-00; Wed, 08 Jan 2003 09:23:03 -0800
From: Randy Bush <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Rick Wesson <[e-mail]>
Cc: Edward Lewis <[e-mail]>, "'[e-mail]'" <[e-mail]>, <[e-mail]>
Subject: Re: privacy
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
Date: Wed, 08 Jan 2003 09:23:03 -0800
Sender: [e-mail]
Precedence: bulk

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

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

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

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

randy



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08NHo9p025718 for <[e-mail]>; Thu, 9 Jan 2003 00:17:50 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h08NHoQo025717 for ietf-provreg-outgoing; Thu, 9 Jan 2003 00:17:50 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from nic-naa.net (216-220-241-233.midmaine.com [216.220.241.233]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08NHm9p025712 for <[e-mail]>; Thu, 9 Jan 2003 00:17:48 +0100 (MET)
Received: from nic-naa.net (localhost.nic-naa.net [127.0.0.1]) by nic-naa.net (8.12.6/8.12.6) with ESMTP id h08NIwGF000515 for <[e-mail]>; Wed, 8 Jan 2003 18:18:58 -0500 (EST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: privacy
Date: Wed, 08 Jan 2003 18:18:58 -0500
From: Eric Brunner-Williams in Portland Maine <[e-mail]>
Sender: [e-mail]
Precedence: bulk

> The problem is that we don't know enough about privacy to know what 
> hooks are needed or what shape they need to take.  Is that accurate?

I've never thought so, but its a consensus thing.

If there is an interoperability issue (paf's note), which presumes
two or more instances of operability, then its interoperability of
mechanisms, not equivalences of policies.

Eric


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08LgE9p024961 for <[e-mail]>; Wed, 8 Jan 2003 22:42:14 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h08LgDKk024960 for ietf-provreg-outgoing; Wed, 8 Jan 2003 22:42:13 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from felix.automagic.org (felix.automagic.org [204.152.186.101]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id h08LgB9p024955 for <[e-mail]>; Wed, 8 Jan 2003 22:42:12 +0100 (MET)
Received: (qmail 27014 invoked by uid 0); 8 Jan 2003 21:42:10 -0000
Received: from localhost.automagic.org (HELO isc.org) (127.0.0.1) by localhost.automagic.org with SMTP; 8 Jan 2003 21:42:10 -0000
Date: Wed, 8 Jan 2003 16:42:34 -0500
Subject: Re: privacy
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: "Hollenbeck, Scott" <[e-mail]>, [e-mail]
To: Edward Lewis <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <a05111b1eba42475d43c1@[192.149.252.226]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: [e-mail]
Precedence: bulk

On Wednesday, Jan 8, 2003, at 16:38 Canada/Eastern, Edward Lewis wrote:

> We are:
>
> ) not being asked to solve general privacy concerns.
> ) not being asked to duct tape in a privacy language
> ) being asked to put reqd hooks into the language to state privacy in 
> the small
>
> The problem is that we don't know enough about privacy to know what 
> hooks are needed or what shape they need to take.  Is that accurate?

That sounds accurate to me.


Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08LcA9p024928 for <[e-mail]>; Wed, 8 Jan 2003 22:38:10 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h08LcAF1024927 for ietf-provreg-outgoing; Wed, 8 Jan 2003 22:38:10 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08Lc89p024922 for <[e-mail]>; Wed, 8 Jan 2003 22:38:09 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h08Lc8Ym071973; Wed, 8 Jan 2003 16:38:08 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA07661; Wed, 8 Jan 2003 16:38:07 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b1eba42475d43c1@[192.149.252.226]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 8 Jan 2003 16:38:09 -0500
To: Joe Abley <[e-mail]>, Edward Lewis <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: privacy
Cc: "Hollenbeck, Scott" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

That's the basic rationale behind the criteria I posted in reference 
to the lastVerified element.

But then there's a dilemma of going to extremes, which is what Patrik 
referred to earlier today.  If you push too much out of the base and 
into the extensions, you run the risk of making the protocol too 
complicated to use.  I can think of two examples - IPsec and DNSSEC. 
With IPsec, it was possible to get desktop software to work with it, 
but only if you know the exact incantation of crypto modules 
available.  With DNSSEC, over time optional ways of working were 
invalidated because it was too hard to use (RFC 3008's updating of 
2535 is an example).

Believe me, this issue is a bit complicated, I'm not sure what the 
base problem is.

We are:

) not being asked to solve general privacy concerns.
) not being asked to duct tape in a privacy language
) being asked to put reqd hooks into the language to state privacy in the small

The problem is that we don't know enough about privacy to know what 
hooks are needed or what shape they need to take.  Is that accurate?

At 16:21 -0500 1/8/03, Joe Abley wrote:
>Absolutely. That sounds like a strong argument in favour of leaving
>contentious (or registry-specific) matters like policy hooks out of the
>base spec, and allowing them to be implemented as extensions.
>
>The base spec should contain the bare minimum functionality in order to
>provide the essential elements common to the vast majority (and hopefully all)
>registries. Putting stuff in there which is necessarily registry-specific
>means registries will have to break the base spec in order to implement it.
>
>
>Joe

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08LLe9p024793 for <[e-mail]>; Wed, 8 Jan 2003 22:21:40 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h08LLeqc024792 for ietf-provreg-outgoing; Wed, 8 Jan 2003 22:21:40 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from felix.automagic.org (felix.automagic.org [204.152.186.101]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id h08LLb9p024787 for <[e-mail]>; Wed, 8 Jan 2003 22:21:38 +0100 (MET)
Received: (qmail 31334 invoked by uid 0); 8 Jan 2003 21:21:36 -0000
Received: from localhost.automagic.org (HELO isc.org) (127.0.0.1) by localhost.automagic.org with SMTP; 8 Jan 2003 21:21:36 -0000
Date: Wed, 8 Jan 2003 16:21:59 -0500
Subject: Re: privacy
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: "Hollenbeck, Scott" <[e-mail]>, [e-mail]
To: Edward Lewis <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <a05111b1bba4243fa7881@[192.149.252.226]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: [e-mail]
Precedence: bulk

On Wednesday, Jan 8, 2003, at 16:11 Canada/Eastern, Edward Lewis wrote:

> Break v. Extend ;)
>
> The way it should work is that if Brand A and Brand B both are 
> compliant (remember that we use interoperable, not compliant though), 
> then both will understand whatever they are compliant with (e.g., the 
> base, extention 1, etc.).  If an extension is needed in the Brand A 
> client to talk with the Brand B server for a given registry, extend 
> the Brand A client should be a matter of adding a software module.
>
> That's how it is supposed to work.

Absolutely. That sounds like a strong argument in favour of leaving 
contentious (or registry-specific) matters like policy hooks out of the 
base spec, and allowing them to be implemented as extensions.

The base spec should contain the bare minimum functionality in order to 
provide the essential elements common to the vast majority (and 
hopefully all) registries. Putting stuff in there which is necessarily 
registry-specific means registries will have to break the base spec in 
order to implement it.


Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08LGq9p024736 for <[e-mail]>; Wed, 8 Jan 2003 22:16:52 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h08LGqFo024735 for ietf-provreg-outgoing; Wed, 8 Jan 2003 22:16:52 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08LGo9p024730 for <[e-mail]>; Wed, 8 Jan 2003 22:16:51 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h08LGmYm070661; Wed, 8 Jan 2003 16:16:48 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA29490; Wed, 8 Jan 2003 16:16:19 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b1bba4243fa7881@[192.149.252.226]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 8 Jan 2003 16:11:52 -0500
To: Joe Abley <[e-mail]>, Edward Lewis <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: privacy
Cc: "Hollenbeck, Scott" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Break v. Extend ;)

The way it should work is that if Brand A and Brand B both are 
compliant (remember that we use interoperable, not compliant though), 
then both will understand whatever they are compliant with (e.g., the 
base, extention 1, etc.).  If an extension is needed in the Brand A 
client to talk with the Brand B server for a given registry, extend 
the Brand A client should be a matter of adding a software module.

That's how it is supposed to work.

At 16:08 -0500 1/8/03, Joe Abley wrote:
>On Wednesday, Jan 8, 2003, at 15:53 Canada/Eastern, Edward Lewis wrote:
>
>>  At 11:15 -0500 1/8/03, Joe Abley wrote:
>>>  I suspect that the requirements need work (or at least they need 
>>>input based
>>>  on real-life registry policy, as opposed to policy assumed by the IESG).
>>
>>  It's not so much the issue for a registry but for a registrar, 
>>which I sense isn't being considered.
>
>I haven't been considering the registrar position much, that's true.
>
>However, if the protocol collides with policies of different 
>registries, then registries are going to be obliged to break the 
>protocol in order to deploy it. You can bet that different 
>registries will break the protocol in different ways.
>
>This does not sound like something that will improve the chances of 
>client interop.
>
>
>Joe

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08L8s9p024600 for <[e-mail]>; Wed, 8 Jan 2003 22:08:54 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h08L8spd024599 for ietf-provreg-outgoing; Wed, 8 Jan 2003 22:08:54 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08L8r9p024594 for <[e-mail]>; Wed, 8 Jan 2003 22:08:53 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h08L8rYm070364; Wed, 8 Jan 2003 16:08:53 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA26651; Wed, 8 Jan 2003 16:08:52 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b1aba4241f90055@[192.149.252.226]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 8 Jan 2003 16:08:53 -0500
To: Randy Bush <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: privacy
Cc: "'[e-mail]'" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 12:40 -0800 1/8/03, Randy Bush wrote:
>>  Excellent point, I could not agree more ... IMHO all of this goes to the
>>  much larger issue of privacy policy across all IETF protocols
>
>nope.  to repeat yet again.  we are not discussing privacy *policy*.
>we are discussing a mechanism by which a wide set of policies may
>be implemented.  operating system theory 101.

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

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

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

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


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08L7s9p024572 for <[e-mail]>; Wed, 8 Jan 2003 22:07:54 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h08L7sYX024571 for ietf-provreg-outgoing; Wed, 8 Jan 2003 22:07:54 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from felix.automagic.org (felix.automagic.org [204.152.186.101]) by nic.cafax.se (8.12.5/8.12.5) with SMTP id h08L7q9p024561 for <[e-mail]>; Wed, 8 Jan 2003 22:07:53 +0100 (MET)
Received: (qmail 20464 invoked by uid 0); 8 Jan 2003 21:07:46 -0000
Received: from localhost.automagic.org (HELO isc.org) (127.0.0.1) by localhost.automagic.org with SMTP; 8 Jan 2003 21:07:46 -0000
Date: Wed, 8 Jan 2003 16:08:08 -0500
Subject: Re: privacy
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: "Hollenbeck, Scott" <[e-mail]>, [e-mail]
To: Edward Lewis <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <a05111b19ba423ef96b16@[192.149.252.226]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
Sender: [e-mail]
Precedence: bulk

On Wednesday, Jan 8, 2003, at 15:53 Canada/Eastern, Edward Lewis wrote:

> At 11:15 -0500 1/8/03, Joe Abley wrote:
>> I suspect that the requirements need work (or at least they need 
>> input based
>> on real-life registry policy, as opposed to policy assumed by the 
>> IESG).
>
> It's not so much the issue for a registry but for a registrar, which I 
> sense isn't being considered.

I haven't been considering the registrar position much, that's true.

However, if the protocol collides with policies of different 
registries, then registries are going to be obliged to break the 
protocol in order to deploy it. You can bet that different registries 
will break the protocol in different ways.

This does not sound like something that will improve the chances of 
client interop.


Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08KwP9p024427 for <[e-mail]>; Wed, 8 Jan 2003 21:58:25 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h08KwPC8024426 for ietf-provreg-outgoing; Wed, 8 Jan 2003 21:58:25 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08KwN9p024421 for <[e-mail]>; Wed, 8 Jan 2003 21:58:23 +0100 (MET)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id h08KwDE6009723; Wed, 8 Jan 2003 12:58:13 -0800 (PST)
Date: Wed, 8 Jan 2003 12:58:50 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: Randy Bush <[e-mail]>
cc: Richard Shockey <[e-mail]>, Stephane Bortzmeyer <[e-mail]>, Edward Lewis <[e-mail]>, "'[e-mail]'" <[e-mail]>, <[e-mail]>
Subject: Re: privacy
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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

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

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

best,

-rick




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08KrZ9p024387 for <[e-mail]>; Wed, 8 Jan 2003 21:53:35 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h08KrZw5024386 for ietf-provreg-outgoing; Wed, 8 Jan 2003 21:53:35 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08KrY9p024381 for <[e-mail]>; Wed, 8 Jan 2003 21:53:34 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h08KrXYm069626; Wed, 8 Jan 2003 15:53:33 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id PAA21005; Wed, 8 Jan 2003 15:53:28 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b19ba423ef96b16@[192.149.252.226]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 8 Jan 2003 15:53:29 -0500
To: Joe Abley <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: privacy
Cc: "'Edward Lewis'" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 11:15 -0500 1/8/03, Joe Abley wrote:
>I suspect that the requirements need work (or at least they need input based
>on real-life registry policy, as opposed to policy assumed by the IESG).

It's not so much the issue for a registry but for a registrar, which 
I sense isn't being considered.

The IETF concern is that a registrar can work with an registry that 
needs no specific privacy statements made in band and can work with a 
registry using another model that does need statements made.  If the 
registrar has to use two different EPP clients then the WG has failed 
to achieve the goal of interoperability.

E.g., if registry 1 uses brand A EPP client/server and registry 2 
uses brand B, the 'caught in the middle' registrar should be able to 
use the client of brand A xor B to talk to the two servers.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08JBk9p023513 for <[e-mail]>; Wed, 8 Jan 2003 20:11:46 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h08JBkSg023512 for ietf-provreg-outgoing; Wed, 8 Jan 2003 20:11:46 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from joy.songbird.com (songbird.com [208.184.79.7]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08JBh9p023505 for <[e-mail]>; Wed, 8 Jan 2003 20:11:44 +0100 (MET)
Received: from rshockeybox.shockey.us (inetgw.va.neustar.com [209.173.53.225]) by joy.songbird.com (8.9.3/8.9.3) with ESMTP id LAA12521; Wed, 8 Jan 2003 11:11:15 -0800
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 08 Jan 2003 14:13:20 -0500
To: Stephane Bortzmeyer <[e-mail]>, Rick Wesson <[e-mail]>
From: Richard Shockey <[e-mail]>
Subject: Re: privacy
Cc: Randy Bush <[e-mail]>, Edward Lewis <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk

One way to solve the problem resign into the list


At 05:50 PM 1/8/2003 +0100, Stephane Bortzmeyer wrote:
>On Wed, Jan 08, 2003 at 08:29:29AM -0800,
>  Rick Wesson <[e-mail]> wrote
>  a message of 32 lines which said:
>
> > IMHO, privacy needs to be addressed in a superset of the protocols (epp,
> > crisp, whois) and a specific group tasked with that job;
>
>This is very reasonable (sorry for the fine members of the Provreg
>group but last-minute attempts to solve a problem as large as the
>privacy policies in a few lines of patch to the I-D are quite
>laughable).

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

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

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

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

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


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


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


##########

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


Dear colleagues,

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

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

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

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

Best for a Happy New Year,

Danny Weitzner

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




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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08JA99p023488 for <[e-mail]>; Wed, 8 Jan 2003 20:10:09 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h08JA9I0023487 for ietf-provreg-outgoing; Wed, 8 Jan 2003 20:10:09 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08JA89p023482 for <[e-mail]>; Wed, 8 Jan 2003 20:10:08 +0100 (MET)
Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h08J8Tgo027012; Wed, 8 Jan 2003 20:08:30 +0100 (MET)
Received: from xfe-ams-312.cisco.com ([144.254.228.205]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 8 Jan 2003 20:09:57 +0100
Received: from cisco.com ([144.254.74.55]) by xfe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Wed, 8 Jan 2003 20:09:57 +0100
Date: Wed, 8 Jan 2003 20:09:48 +0100
Subject: Re: privacy
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: Edward Lewis <[e-mail]>, "'[e-mail]'" <[e-mail]>, <[e-mail]>
To: Rick Wesson <[e-mail]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
X-OriginalArrivalTime: 08 Jan 2003 19:09:57.0361 (UTC) FILETIME=[88B14610:01C2B749]
Sender: [e-mail]
Precedence: bulk

Let me rephrase what I heard IESG saying, as sponsoring AD for this 
document. As IESG is cc:ed people can jump in and correct me, or add 
more/different things.

First IESG completely agree the issues with privacy is complicated. The 
laws and requirements in different countries are very different, and 
basically differ in for example the following ways for "white-pages 
information":

  - Whether opt-in or opt-out in a public database is the function needed
  - Whether the opt-in/opt-out is allowed to be implicit, or if it
    must be implicit
  - What information a registry can say is mandatory to allow being
    public
  - ...

These requirements which certainly differ not only between registries 
but also what legislation the registrant belong to is clear. In various 
communities discussions exists wether for example it is ok for the 
registry outside of Sweden to publicly publish social information about 
a domain name holder from Sweden if the registrant is a private person. 
The input I have got from lawyers in Sweden is that publication of such 
information in whois is not ok if not the registrant has explicitly 
said yes to it. And, competition legislation say it is not ok for a 
registry to require this (implicit opt-in) to get the service.

Of course, these people I have talked with can be wrong, but similar 
examples exists in Austria, Switzerland and the Netherlands. This issue 
is discussed heavily in for example CENTR Legal group (I forgot the 
name of this group) because the "requirements" ICANN has put on whois 
and ccTLD is violating the local law in some countries.

These differences together with the requirement in RFC 3375 that the 
protocol MUST be able to handle the cases that one have:

  - multiple registrars connected to one registry
  - one registrar connecting to multiple registries
  - one object being associated with other objects, possibly under
    authoritative control of a different registrar
  - one registry being thin, another thick (when looking at
    where social information is stored)

These three rules are just some signs that the protocol MUST be 
something which is interoperable between multiple implementations, and 
this in turn lead to the need for multiple implementations which can 
handle the various permutations of legal rules for handling of the 
social information about a registrant.

Now, what IESG is concerned about is _INTEROPERABILITY_, not so much 
privacy.

Are you surprised? I hope not.

Now, IF the wg explain in the specification of epp how interoperability 
in the real world is guaranteed, then we are done. Interoperability in 
mixed environments when multiple different privacy models are used.

Does this explain the issue better?

    paf


On onsdag, jan 8, 2003, at 18:35 Europe/Stockholm, Rick Wesson wrote:

>
> Patrik,
>
>> What IESG want is _some_ mandatory to implement mechanism which makes
>> it possible for the registrar to say to the registry "Do not disclose
>> this attribute to a third party". If the wg want to have the mandatory
>> to implement mechanism more powerful than that, fine. What is not ok 
>> is
>> the protocol not having any mandatory to implement privacy mechanism 
>> in
>> it, only extensions.
>
> The issue that some folks have with and IESG mandatory to implement
> privacy capability in the prov-reg domain registration context is that
> addressing privacy just in epp is not a solution. Addressing privacy in
> epp also requires addressing it in the publishing protocols.
>
> privacy is a thick issues and I've not seen/herd one prov-reg 
> participant
> stand up and say "we understand privacy and here is what should happen"
> What we do see on the list and in the meetings is that we are not the
> people who should develop a privacy context and we don't know how to do
> it.
>
> we have asked for additional direction and get a responses that are 
> obtuse
> and confusing. Everyone appears to agree that privacy is a more complex
> issue than the IESG is willing to accept and that provreg may not be 
> the
> place to define such capabilities.
>
> I request that you consider that this working group may not be capable 
> of
> addressing the problem and appreciate your thoughts on the next step if
> this proves to be true.
>
> -rick
>
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08Iq59p023286 for <[e-mail]>; Wed, 8 Jan 2003 19:52:05 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h08Iq5iK023285 for ietf-provreg-outgoing; Wed, 8 Jan 2003 19:52:05 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08Iq49p023280 for <[e-mail]>; Wed, 8 Jan 2003 19:52:04 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h08Iq1Ym064513 for <[e-mail]>; Wed, 8 Jan 2003 13:52:01 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA06539; Wed, 8 Jan 2003 13:52:00 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0fba4220af5942@[192.149.252.226]>
Date: Wed, 8 Jan 2003 13:51:58 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: mail list traffic
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Pertinent to the discussion on privacy, I fear that our list's spam 
protection is halting some messages.  Randy has sent an answer to the 
privacy topic that has not appeared on the mailing list.  (It just 
dawned on me why.)  I think one from Richard Shockey shares the same 
fate.

I don't have the keys to the mail list management software (if 
they've been given to me, I've lost them), so I need to ask Jaap (or 
whoever else is at the controls) if (t)he(y) could look through the 
held messages and approve any on the topic.

I'm putting this out publicly just to let folks know that there's an 
effort to get the public discussion going from all angles, we're just 
suffering some technical difficulties.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08Ioo9p023267 for <[e-mail]>; Wed, 8 Jan 2003 19:50:50 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h08Ioohv023266 for ietf-provreg-outgoing; Wed, 8 Jan 2003 19:50:50 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08Ion9p023261 for <[e-mail]>; Wed, 8 Jan 2003 19:50:49 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h08IojYm064384; Wed, 8 Jan 2003 13:50:45 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA05969; Wed, 8 Jan 2003 13:50:43 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b10ba4221f2a4f4@[192.149.252.226]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 8 Jan 2003 13:49:45 -0500
To: Stephane Bortzmeyer <[e-mail]>, Rick Wesson <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: privacy
Cc: Randy Bush <[e-mail]>, Edward Lewis <[e-mail]>, "'[e-mail]'" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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

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

At 17:50 +0100 1/8/03, Stephane Bortzmeyer wrote:
>On Wed, Jan 08, 2003 at 08:29:29AM -0800,
>  Rick Wesson <[e-mail]> wrote
>  a message of 32 lines which said:
>
>>  IMHO, privacy needs to be addressed in a superset of the protocols (epp,
>>  crisp, whois) and a specific group tasked with that job;
>
>This is very reasonable (sorry for the fine members of the Provreg
>group but last-minute attempts to solve a problem as large as the
>privacy policies in a few lines of patch to the I-D are quite
>laughable).
>
>But such a group already exists: W3C's P3P group. P3P can be used for
>more than Web sites and they are willing to do what it needs to extend
>their framework to registry privacy policies.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08HnS9p022652 for <[e-mail]>; Wed, 8 Jan 2003 18:49:28 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h08HnSBo022651 for ietf-provreg-outgoing; Wed, 8 Jan 2003 18:49:28 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08HnQ9p022646 for <[e-mail]>; Wed, 8 Jan 2003 18:49:27 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA28786; Wed, 8 Jan 2003 12:49:22 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <ZHNYDT79>; Wed, 8 Jan 2003 12:48:37 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Joe Abley'" <[e-mail]>
Cc: "'Edward Lewis'" <[e-mail]>, [e-mail]
Subject: RE: privacy
Date: Wed, 8 Jan 2003 12:47:24 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> For example, I had assumed that the attributes proposal would 
> at least 
> meet the requirements of gTLD registries, since you raised it, but 
> Rick's comments earlier seem to suggest otherwise. Is there *any* 
> registry you know of for whom the attributes proposal is comnpatible 
> with an existing privacy policy?

I'm not familiar with the privacy nuances of the 200+ ccTLD registries, but
I do believe the attribute proposal could work for the ICANN gTLD registries
if we had the freedom to decide what gets disclosed and what doesn't get
disclosed.  As Rick noted we currently operate under terms negotiated with
ICANN that require disclosure of much information, but that doesn't mean
that those terms will remain constant -- especially since the topic of data
privacy is currently being debated within ICANN.

If I remember correctly, Jaap did say somewhere on the list that the
proposal could work for .nl...

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08HZ19p022489 for <[e-mail]>; Wed, 8 Jan 2003 18:35:01 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h08HZ1Wv022488 for ietf-provreg-outgoing; Wed, 8 Jan 2003 18:35:01 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08HYx9p022483 for <[e-mail]>; Wed, 8 Jan 2003 18:35:00 +0100 (MET)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id h08HYqE6018617; Wed, 8 Jan 2003 09:34:52 -0800 (PST)
Date: Wed, 8 Jan 2003 09:35:27 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>
cc: Edward Lewis <[e-mail]>, "'[e-mail]'" <[e-mail]>, <[e-mail]>
Subject: Re: privacy
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Patrik,

> What IESG want is _some_ mandatory to implement mechanism which makes
> it possible for the registrar to say to the registry "Do not disclose
> this attribute to a third party". If the wg want to have the mandatory
> to implement mechanism more powerful than that, fine. What is not ok is
> the protocol not having any mandatory to implement privacy mechanism in
> it, only extensions.

The issue that some folks have with and IESG mandatory to implement
privacy capability in the prov-reg domain registration context is that
addressing privacy just in epp is not a solution. Addressing privacy in
epp also requires addressing it in the publishing protocols.

privacy is a thick issues and I've not seen/herd one prov-reg participant
stand up and say "we understand privacy and here is what should happen"
What we do see on the list and in the meetings is that we are not the
people who should develop a privacy context and we don't know how to do
it.

we have asked for additional direction and get a responses that are obtuse
and confusing. Everyone appears to agree that privacy is a more complex
issue than the IESG is willing to accept and that provreg may not be the
place to define such capabilities.

I request that you consider that this working group may not be capable of
addressing the problem and appreciate your thoughts on the next step if
this proves to be true.

-rick




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08HXN9p022458 for <[e-mail]>; Wed, 8 Jan 2003 18:33:23 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h08HXN4j022457 for ietf-provreg-outgoing; Wed, 8 Jan 2003 18:33:23 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from fep01-mail.bloor.is.net.cable.rogers.com (fep01-mail.bloor.is.net.cable.rogers.com [66.185.86.71]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08HXL9p022452 for <[e-mail]>; Wed, 8 Jan 2003 18:33:22 +0100 (MET)
Received: from isc.org ([24.103.90.17]) by fep01-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <[e-mail]>; Wed, 8 Jan 2003 12:32:48 -0500
Date: Wed, 8 Jan 2003 12:33:36 -0500
Subject: Re: privacy
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: "'Edward Lewis'" <[e-mail]>, [e-mail]
To: "Hollenbeck, Scott" <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.103.90.17] using ID <[e-mail]> at Wed, 8 Jan 2003 12:32:48 -0500
Sender: [e-mail]
Precedence: bulk

On Wednesday, Jan 8, 2003, at 12:21 Canada/Eastern, Hollenbeck, Scott 
wrote:

>> Would it be possible to hear the set of requirements to which the
>> attribute solution forms an acceptable solution?
>
> The requirements as discussed between myself, the chairs, and the 
> interested
> IESG members have been sent to the mailing list at least three times:
>
> http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00041.html
>
> http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00100.html
>
> http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00004.html
>
> One can argue that these messages aren't exactly a formal requirements
> specification, but this is what we've been working with.

Hmm, the only part of those I can see that looks like a requirements 
analysis is this:

> What IESG want is _some_ mandatory to implement mechanism which makes
> it possible for the registrar to say to the registry "Do not disclose
> this attribute to a third party". If the wg want to have the mandatory
> to implement mechanism more powerful than that, fine. What is not ok is
> the protocol not having any mandatory to implement privacy mechanism in
> it, only extensions.

The rest is discussion about possible solutions.

If that's all the requirements analysis there is, then I think the 
chances of coming up with an implementation that will be actually 
useful to registries are rather slim.

For example, I had assumed that the attributes proposal would at least 
meet the requirements of gTLD registries, since you raised it, but 
Rick's comments earlier seem to suggest otherwise. Is there *any* 
registry you know of for whom the attributes proposal is comnpatible 
with an existing privacy policy?

The needs of registries seem like a good starting point for this, 
wherever this work is done (assuming it is done). Starting out with an 
implementation and working back to see how it can be shoe-horned into 
registries seems like a waste of time: regardless of how mandatory 
these attributes are made in the draft spec, if they don't fit, 
registries won't use them.


Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08HSZ9p022405 for <[e-mail]>; Wed, 8 Jan 2003 18:28:35 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h08HSZ6a022404 for ietf-provreg-outgoing; Wed, 8 Jan 2003 18:28:35 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from zak.ecotroph.net (zak.ecotroph.net [216.38.143.123]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08HSY9p022399 for <[e-mail]>; Wed, 8 Jan 2003 18:28:34 +0100 (MET)
Received: from ecotroph.net ([::ffff:216.168.239.87]) (AUTH: LOGIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by zak.ecotroph.net with esmtp; Wed, 08 Jan 2003 12:28:32 -0500
Message-ID: <[e-mail]>
Date: Wed, 08 Jan 2003 12:32:56 -0500
From: Andrew Newton <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Rick Wesson <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: privacy
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Rick Wesson wrote:
>>
>>the iesg members specifically said we did not want to decide the method,
>>though some decades of programming practice does suggest one.  what we
>>do care is that there is a mechanism which may be invoked by policy.
> 
> would you please discuss your rationale in the light that all gTLD
> registrations will also be published in the whois negating any utility of
> your requirement.
> 
> furthermore, since gTLD registries and registrars (the primary users of
> this work product) are required by contract to publicly publish this
> information, the paries using this privacy enhanced protocol would be
> exposed to a serious liability concern as registrants expect information to
> be private but contracts require it be published.

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

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

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

-andy




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08HNQ9p022352 for <[e-mail]>; Wed, 8 Jan 2003 18:23:26 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h08HNQJU022351 for ietf-provreg-outgoing; Wed, 8 Jan 2003 18:23:26 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08HNO9p022346 for <[e-mail]>; Wed, 8 Jan 2003 18:23:25 +0100 (MET)
Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA27159; Wed, 8 Jan 2003 12:23:20 -0500 (EST)
Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <ZHNYDTH6>; Wed, 8 Jan 2003 12:22:34 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Joe Abley'" <[e-mail]>
Cc: "'Edward Lewis'" <[e-mail]>, [e-mail]
Subject: RE: privacy
Date: Wed, 8 Jan 2003 12:21:21 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> Would it be possible to hear the set of requirements to which the 
> attribute solution forms an acceptable solution?

The requirements as discussed between myself, the chairs, and the interested
IESG members have been sent to the mailing list at least three times:

http://www.cafax.se/ietf-provreg/maillist/2002-10/msg00041.html

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

http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00004.html

One can argue that these messages aren't exactly a formal requirements
specification, but this is what we've been working with.

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08GoO9p021957 for <[e-mail]>; Wed, 8 Jan 2003 17:50:24 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h08GoNfB021956 for ietf-provreg-outgoing; Wed, 8 Jan 2003 17:50:23 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08GoM9p021951 for <[e-mail]>; Wed, 8 Jan 2003 17:50:23 +0100 (MET)
Received: from vespucci.nic.fr ([e-mail] [192.134.4.68]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id h08GoHkS533795; Wed, 8 Jan 2003 17:50:18 +0100 (CET)
Received: by vespucci.nic.fr (Postfix, from userid 1055) id 6ADC910E42; Wed,  8 Jan 2003 17:50:17 +0100 (CET)
Date: Wed, 8 Jan 2003 17:50:17 +0100
From: Stephane Bortzmeyer <[e-mail]>
To: Rick Wesson <[e-mail]>
Cc: Randy Bush <[e-mail]>, Edward Lewis <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: privacy
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.28i
X-Operating-System: Debian GNU/Linux 3.0
X-Kernel: Linux 2.4.18-686 i686
Organization: NIC France
X-URL: http://www.nic.fr/
Sender: [e-mail]
Precedence: bulk

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

> IMHO, privacy needs to be addressed in a superset of the protocols (epp,
> crisp, whois) and a specific group tasked with that job; 

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

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08GT99p021679 for <[e-mail]>; Wed, 8 Jan 2003 17:29:09 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h08GT9pb021678 for ietf-provreg-outgoing; Wed, 8 Jan 2003 17:29:09 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com (bean.ar.com [66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08GT79p021670 for <[e-mail]>; Wed, 8 Jan 2003 17:29:08 +0100 (MET)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id h08GSsE6011470; Wed, 8 Jan 2003 08:28:55 -0800 (PST)
Date: Wed, 8 Jan 2003 08:29:29 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: Randy Bush <[e-mail]>
cc: Edward Lewis <[e-mail]>, "'[e-mail]'" <[e-mail]>, <[e-mail]>
Subject: Re: privacy
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Randy,


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

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

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

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

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

-rick




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08GFD9p021548 for <[e-mail]>; Wed, 8 Jan 2003 17:15:13 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h08GFDZk021547 for ietf-provreg-outgoing; Wed, 8 Jan 2003 17:15:13 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from fep04-mail.bloor.is.net.cable.rogers.com (fep04-mail.bloor.is.net.cable.rogers.com [66.185.86.74]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08GFB9p021542 for <[e-mail]>; Wed, 8 Jan 2003 17:15:11 +0100 (MET)
Received: from isc.org ([24.103.90.17]) by fep04-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.05.06 201-253-122-126-106-20020509) with ESMTP id <20[e-mail]>; Wed, 8 Jan 2003 11:14:21 -0500
Date: Wed, 8 Jan 2003 11:15:22 -0500
Subject: Re: privacy
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: "'Edward Lewis'" <[e-mail]>, [e-mail]
To: "Hollenbeck, Scott" <[e-mail]>
From: Joe Abley <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
X-Authentication-Info: Submitted using SMTP AUTH PLAIN at fep04-mail.bloor.is.net.cable.rogers.com from [24.103.90.17] using ID <[e-mail]> at Wed, 8 Jan 2003 11:14:21 -0500
Sender: [e-mail]
Precedence: bulk

On Wednesday, Jan 8, 2003, at 07:17 Canada/Eastern, Hollenbeck, Scott 
wrote:

>> The crux of the issue is, there are situations in which a registrar
>> may wish to alter the default privacy considerations for data when
>> interacting with a registry.  Not all registrar-registry environments
>> will need this flexibility, but there is a claim that some exist.  (I
>> have no personal, first-hand knowledge of any such environments.)
>>
>> How can we accomodate such environments?  That is the basic question.
>
> FWIW the attribute-based proposal is the one most closely aligned with
> "standard" XML practice, if such a thing exists.  XML attributes are
> typically used to describe the data contained within an element, and 
> that's
> what's being proposed.

Would it be possible to hear the set of requirements to which the 
attribute solution forms an acceptable solution?

I suspect that the requirements need work (or at least they need input 
based on real-life registry policy, as opposed to policy assumed by the 
IESG).

As Rick mentioned, if the IESG could raise their concerns on this list 
it would be a lot easier to understand where they are coming from.


Joe



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08CJl9p019594 for <[e-mail]>; Wed, 8 Jan 2003 13:19:47 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h08CJl92019593 for ietf-provreg-outgoing; Wed, 8 Jan 2003 13:19:47 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from crow.verisign.com (crow.verisign.com [216.168.237.103]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h08CJj9p019588 for <[e-mail]>; Wed, 8 Jan 2003 13:19:46 +0100 (MET)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by crow.verisign.com (nsi_0.1/8.9.1) with ESMTP id HAA11147; Wed, 8 Jan 2003 07:19:41 -0500 (EST)
Received: by VSVAPOSTALGW1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <ZHNVDFCZ>; Wed, 8 Jan 2003 07:17:43 -0500
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Edward Lewis'" <[e-mail]>, [e-mail]
Subject: RE: privacy
Date: Wed, 8 Jan 2003 07:17:41 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> The crux of the issue is, there are situations in which a registrar 
> may wish to alter the default privacy considerations for data when 
> interacting with a registry.  Not all registrar-registry environments 
> will need this flexibility, but there is a claim that some exist.  (I 
> have no personal, first-hand knowledge of any such environments.)
> 
> How can we accomodate such environments?  That is the basic question.

FWIW the attribute-based proposal is the one most closely aligned with
"standard" XML practice, if such a thing exists.  XML attributes are
typically used to describe the data contained within an element, and that's
what's being proposed.

The other proposal I floated (the <doNotDisclose> proposal) could also work,
but it means carrying the same element data twice: once in the "normal"
place and a second time to mark it.  I can understand why some of the folks
who've been doing implementations might find it easier to incorporate into
current code, but I don't think it's the best architectural solution.

Just my two cents...

-Scott-


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h089Rm9p018306 for <[e-mail]>; Wed, 8 Jan 2003 10:27:48 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h089Rm2w018305 for ietf-provreg-outgoing; Wed, 8 Jan 2003 10:27:48 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h089Rl9p018300 for <[e-mail]>; Wed, 8 Jan 2003 10:27:47 +0100 (MET)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.5/8.12.5) with ESMTP id h089RhOG004544 for <[e-mail]>; Wed, 8 Jan 2003 10:27:43 +0100 (CET) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.5/8.12.5/Submit) id h089RgOY004543 for [e-mail]; Wed, 8 Jan 2003 10:27:42 +0100 (CET)
Received: from willow.neustar.com (willow.neustar.com [209.173.53.84]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h07NAn9p013940 for <[e-mail]>; Wed, 8 Jan 2003 00:10:49 +0100 (MET)
Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h07NAP814156; Tue, 7 Jan 2003 23:10:25 GMT
Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id <ZH2JF33M>; Tue, 7 Jan 2003 18:12:46 -0500
Message-ID: <[e-mail]>
From: "McGarry, Tom" <[e-mail]>
To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: Edward Lewis <[e-mail]>
Subject: RE: privacy
Date: Tue, 7 Jan 2003 18:12:34 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h07NAo9p013941
Sender: [e-mail]
Precedence: bulk

I don't think you've explained why the IESG wants this to be mandatory?  (If
you have, I apologize, can you repeat it or point us to it?)

-----Original Message-----
From: Patrik Fältström [mailto:[e-mail]]
Sent: Tuesday, January 07, 2003 5:29 PM
To: Rick Wesson
Cc: Edward Lewis; '[e-mail]'; [e-mail]; [e-mail]
Subject: Re: privacy


On tisdag, jan 7, 2003, at 22:43 Europe/Stockholm, Rick Wesson wrote:

> I have some thoughts on this. I prefered the capability in scott's 
> second
> to the last proposal [1] -- I also have an issue with the IESG deciding
> what in the most appropiate methodology.

What IESG want is _some_ mandatory to implement mechanism which makes 
it possible for the registrar to say to the registry "Do not disclose 
this attribute to a third party". If the wg want to have the mandatory 
to implement mechanism more powerful than that, fine. What is not ok is 
the protocol not having any mandatory to implement privacy mechanism in 
it, only extensions.

> finally I would appreciate it if the IESG would post these discussion 
> to
> the public list as private discussions are just that, private.

The issues IESG has are posted on the I-D tracker, and it is up to the 
editor and wg chair (and that way the wg) how to resolve the issues. 
What we as IESG members have got are suggestions on solutions, and we 
have (as far as I remember) said yes to all proposals.

What we have heard back from wg chairs etc is that they have got 
private messages back from wg members which have issues with the 
proposals, issues with privacy being mandatory _at_all_. They have 
checked with IESG whether things really need to be mandatory, and the 
answer is yes.

What is the difference between what you here point to, and what Scott 
might have proposed later, I can not say, and I don't know if any of 
the IESG members can say straight from our head. We have many documents 
to look at, and we have posted the issues we have on the I-D tracker. 
We must trust the wg chair being able to solve the problem in one way 
or another, and come back to us with updated documents.

    paf

> Since we
> are discussing the privacy of end-users information (that will 
> eventually
> be published in whois) it seems silly that we are not involved in the
> discussion and decision process on this topic.
>
> Lets put the proposal [1] back on the table and if the IESG has an 
> issue
> with it lets here from the IESG in this wg, not through our
> DOCUMENT-EDITOR or the CHAIR but involve those members of the IESG that
> have a problem with it.
>
>
>
> -rick
>
> [1] http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00093.html
>
>
>
>
> On Tue, 7 Jan 2003, Edward Lewis wrote:
>
>> Over the past few weeks the primary concern of the WG has been
>> preparing an answer to the IESG comments.  The one sticking point has
>> been the comment to provide privacy information at a more granular
>> level that we now provide.
>>
>> There was a meeting of the IESG members involved, your chairs, and
>> Scott to review the state of the issue last month.  The outcome of
>> that phone call was sent by Scott to the list.  I've seen responses
>> from just two folks publicly and one privately.  I've been hoping for
>> more - and more positive responses.
>>
>> First I want to make it clear that Scott isn't pushing this issue
>> back on to the table because we wants to.  This is an issue on which
>> we are getting feedback from the IESG, and they hold sway over our
>> documents, as in they have the final word.  They are reasonable
>> folks, but they do hold the final word.
>>
>> I promised Scott that I'd wait until today to let folks that have
>> been out of the office over the past two weeks (plus a day to
>> download all the pending mail) before prompting the group another
>> time to consider this issue.
>>
>> The crux of the issue is, there are situations in which a registrar
>> may wish to alter the default privacy considerations for data when
>> interacting with a registry.  Not all registrar-registry environments
>> will need this flexibility, but there is a claim that some exist.  (I
>> have no personal, first-hand knowledge of any such environments.)
>>
>> How can we accomodate such environments?  That is the basic question.
>>
>> The most recent thread on this begins with:
>>       http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00100.html
>>
>> Next: Milestones, ROID and other issues...
>> --
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> Edward Lewis                                          [phone]
>> ARIN Research Engineer
>>
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h07MT29p013606 for <[e-mail]>; Tue, 7 Jan 2003 23:29:02 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h07MT2qk013605 for ietf-provreg-outgoing; Tue, 7 Jan 2003 23:29:02 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h07MT19p013600 for <[e-mail]>; Tue, 7 Jan 2003 23:29:01 +0100 (MET)
Received: from xbe-ams-313.cisco.com (localhost [127.0.0.1]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h07MRGHo028308; Tue, 7 Jan 2003 23:27:16 +0100 (MET)
Received: from xfe-ams-311.cisco.com ([144.254.228.204]) by xbe-ams-313.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 7 Jan 2003 23:28:44 +0100
Received: from cisco.com ([144.254.74.55]) by xfe-ams-311.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Tue, 7 Jan 2003 23:28:43 +0100
Date: Tue, 7 Jan 2003 23:28:40 +0100
Subject: Re: privacy
Content-Type: text/plain; charset=US-ASCII; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: Edward Lewis <[e-mail]>, "'[e-mail]'" <[e-mail]>, <[e-mail]>, <[e-mail]>
To: Rick Wesson <[e-mail]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[e-mail]>
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.551)
X-OriginalArrivalTime: 07 Jan 2003 22:28:43.0841 (UTC) FILETIME=[2303F310:01C2B69C]
Sender: [e-mail]
Precedence: bulk

On tisdag, jan 7, 2003, at 22:43 Europe/Stockholm, Rick Wesson wrote:

> I have some thoughts on this. I prefered the capability in scott's 
> second
> to the last proposal [1] -- I also have an issue with the IESG deciding
> what in the most appropiate methodology.

What IESG want is _some_ mandatory to implement mechanism which makes 
it possible for the registrar to say to the registry "Do not disclose 
this attribute to a third party". If the wg want to have the mandatory 
to implement mechanism more powerful than that, fine. What is not ok is 
the protocol not having any mandatory to implement privacy mechanism in 
it, only extensions.

> finally I would appreciate it if the IESG would post these discussion 
> to
> the public list as private discussions are just that, private.

The issues IESG has are posted on the I-D tracker, and it is up to the 
editor and wg chair (and that way the wg) how to resolve the issues. 
What we as IESG members have got are suggestions on solutions, and we 
have (as far as I remember) said yes to all proposals.

What we have heard back from wg chairs etc is that they have got 
private messages back from wg members which have issues with the 
proposals, issues with privacy being mandatory _at_all_. They have 
checked with IESG whether things really need to be mandatory, and the 
answer is yes.

What is the difference between what you here point to, and what Scott 
might have proposed later, I can not say, and I don't know if any of 
the IESG members can say straight from our head. We have many documents 
to look at, and we have posted the issues we have on the I-D tracker. 
We must trust the wg chair being able to solve the problem in one way 
or another, and come back to us with updated documents.

    paf

> Since we
> are discussing the privacy of end-users information (that will 
> eventually
> be published in whois) it seems silly that we are not involved in the
> discussion and decision process on this topic.
>
> Lets put the proposal [1] back on the table and if the IESG has an 
> issue
> with it lets here from the IESG in this wg, not through our
> DOCUMENT-EDITOR or the CHAIR but involve those members of the IESG that
> have a problem with it.
>
>
>
> -rick
>
> [1] http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00093.html
>
>
>
>
> On Tue, 7 Jan 2003, Edward Lewis wrote:
>
>> Over the past few weeks the primary concern of the WG has been
>> preparing an answer to the IESG comments.  The one sticking point has
>> been the comment to provide privacy information at a more granular
>> level that we now provide.
>>
>> There was a meeting of the IESG members involved, your chairs, and
>> Scott to review the state of the issue last month.  The outcome of
>> that phone call was sent by Scott to the list.  I've seen responses
>> from just two folks publicly and one privately.  I've been hoping for
>> more - and more positive responses.
>>
>> First I want to make it clear that Scott isn't pushing this issue
>> back on to the table because we wants to.  This is an issue on which
>> we are getting feedback from the IESG, and they hold sway over our
>> documents, as in they have the final word.  They are reasonable
>> folks, but they do hold the final word.
>>
>> I promised Scott that I'd wait until today to let folks that have
>> been out of the office over the past two weeks (plus a day to
>> download all the pending mail) before prompting the group another
>> time to consider this issue.
>>
>> The crux of the issue is, there are situations in which a registrar
>> may wish to alter the default privacy considerations for data when
>> interacting with a registry.  Not all registrar-registry environments
>> will need this flexibility, but there is a claim that some exist.  (I
>> have no personal, first-hand knowledge of any such environments.)
>>
>> How can we accomodate such environments?  That is the basic question.
>>
>> The most recent thread on this begins with:
>>       http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00100.html
>>
>> Next: Milestones, ROID and other issues...
>> --
>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>> Edward Lewis                                          [phone]
>> ARIN Research Engineer
>>
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h07M4d9p013415 for <[e-mail]>; Tue, 7 Jan 2003 23:04:39 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h07M4c1d013414 for ietf-provreg-outgoing; Tue, 7 Jan 2003 23:04:38 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h07M4a9p013409 for <[e-mail]>; Tue, 7 Jan 2003 23:04:38 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h07M4XYm039464; Tue, 7 Jan 2003 17:04:33 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA18337; Tue, 7 Jan 2003 17:04:32 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b04ba40fb88e4f6@[192.149.252.226]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 7 Jan 2003 17:04:25 -0500
To: Rick Wesson <[e-mail]>, Edward Lewis <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: privacy
Cc: "'[e-mail]'" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Note that I cut off the IESG from the reply - this isn't something to 
clutter them up with.

In as mush as I appreciate where Rick's coming from, I'd just like to 
solve the problem at hand, the privacy issue.  Issues concerning the 
IESG interface (I admit that there are some in general) are being 
discussed elsewhere, i.e.:
    ([e-mail] for subscriptions to that).

It's not that I don't want to hear about IESG interface problem - 
even though I really don't - it's that I don't want to hear about 
that issue here.  If you get my drift.

Okay, but I did say that we are stuck because the IESG has said we 
have to address their concerns.  I meant this to be the reason why 
Scott has had the unenviable task of raising once again the privacy 
issue.  I did not mean this to be a complaint about the IESG 
stonewalling us.  If the WG has sufficient reason for us to not 
address an IESG comment, we need to build a case for that.  It's not 
like the IESG can't change their mind about an issue.

As far as the privacy issue discussion, everything that was discussed 
between "us" has been posted to the provreg list.  BTW, the entire 
call was on clarifying the comments on privacy (which are on the mail 
list archive site).  No document modifying "decisions" or even 
suggestions were made.

Let me ask this of the WG group:

Is there a reason not to add more granularity to the privacy specification?

Should we strive to add granularity?
Should we not strive to add granularity?

At 13:43 -0800 1/7/03, Rick Wesson wrote:
>Ed,
>
>I have some thoughts on this. I prefered the capability in scott's second
>to the last proposal [1] -- I also have an issue with the IESG deciding
>what in the most appropiate methodology.
>
>finally I would appreciate it if the IESG would post these discussion to
>the public list as private discussions are just that, private. Since we
>are discussing the privacy of end-users information (that will eventually
>be published in whois) it seems silly that we are not involved in the
>discussion and decision process on this topic.
>
>Lets put the proposal [1] back on the table and if the IESG has an issue
>with it lets here from the IESG in this wg, not through our
>DOCUMENT-EDITOR or the CHAIR but involve those members of the IESG that
>have a problem with it.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h07LiC9p013220 for <[e-mail]>; Tue, 7 Jan 2003 22:44:12 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h07LiCRt013219 for ietf-provreg-outgoing; Tue, 7 Jan 2003 22:44:12 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bean.ar.com ([66.123.187.68]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h07LiA9p013214 for <[e-mail]>; Tue, 7 Jan 2003 22:44:11 +0100 (MET)
Received: from flash.ar.com (wessorh@flash [66.123.187.80]) by bean.ar.com (8.12.6/8.12.6) with ESMTP id h07LhQE6014849; Tue, 7 Jan 2003 13:43:26 -0800 (PST)
Date: Tue, 7 Jan 2003 13:43:57 -0800 (PST)
From: Rick Wesson <[e-mail]>
To: Edward Lewis <[e-mail]>
cc: "'[e-mail]'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: privacy
In-Reply-To: <a05111b00ba40da893fcc@[192.149.252.226]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

Ed,

I have some thoughts on this. I prefered the capability in scott's second
to the last proposal [1] -- I also have an issue with the IESG deciding
what in the most appropiate methodology.

finally I would appreciate it if the IESG would post these discussion to
the public list as private discussions are just that, private. Since we
are discussing the privacy of end-users information (that will eventually
be published in whois) it seems silly that we are not involved in the
discussion and decision process on this topic.

Lets put the proposal [1] back on the table and if the IESG has an issue
with it lets here from the IESG in this wg, not through our
DOCUMENT-EDITOR or the CHAIR but involve those members of the IESG that
have a problem with it.



-rick

[1] http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00093.html




On Tue, 7 Jan 2003, Edward Lewis wrote:

> Over the past few weeks the primary concern of the WG has been
> preparing an answer to the IESG comments.  The one sticking point has
> been the comment to provide privacy information at a more granular
> level that we now provide.
>
> There was a meeting of the IESG members involved, your chairs, and
> Scott to review the state of the issue last month.  The outcome of
> that phone call was sent by Scott to the list.  I've seen responses
> from just two folks publicly and one privately.  I've been hoping for
> more - and more positive responses.
>
> First I want to make it clear that Scott isn't pushing this issue
> back on to the table because we wants to.  This is an issue on which
> we are getting feedback from the IESG, and they hold sway over our
> documents, as in they have the final word.  They are reasonable
> folks, but they do hold the final word.
>
> I promised Scott that I'd wait until today to let folks that have
> been out of the office over the past two weeks (plus a day to
> download all the pending mail) before prompting the group another
> time to consider this issue.
>
> The crux of the issue is, there are situations in which a registrar
> may wish to alter the default privacy considerations for data when
> interacting with a registry.  Not all registrar-registry environments
> will need this flexibility, but there is a claim that some exist.  (I
> have no personal, first-hand knowledge of any such environments.)
>
> How can we accomodate such environments?  That is the basic question.
>
> The most recent thread on this begins with:
>       http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00100.html
>
> Next: Milestones, ROID and other issues...
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                          [phone]
> ARIN Research Engineer
>



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h07JeS9p012136 for <[e-mail]>; Tue, 7 Jan 2003 20:40:28 +0100 (MET)
Received: by nic.cafax.se (8.12.5/8.12.5/Submit) id h07JeSY4012135 for ietf-provreg-outgoing; Tue, 7 Jan 2003 20:40:28 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h07JeR9p012130 for <[e-mail]>; Tue, 7 Jan 2003 20:40:27 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h07JeQYm023331 for <[e-mail]>; Tue, 7 Jan 2003 14:40:26 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA26089; Tue, 7 Jan 2003 14:40:26 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1 (Unverified)
Message-Id: <a05111b00ba40da893fcc@[192.149.252.226]>
Date: Tue, 7 Jan 2003 14:40:21 -0500
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: privacy
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

Over the past few weeks the primary concern of the WG has been 
preparing an answer to the IESG comments.  The one sticking point has 
been the comment to provide privacy information at a more granular 
level that we now provide.

There was a meeting of the IESG members involved, your chairs, and 
Scott to review the state of the issue last month.  The outcome of 
that phone call was sent by Scott to the list.  I've seen responses 
from just two folks publicly and one privately.  I've been hoping for 
more - and more positive responses.

First I want to make it clear that Scott isn't pushing this issue 
back on to the table because we wants to.  This is an issue on which 
we are getting feedback from the IESG, and they hold sway over our 
documents, as in they have the final word.  They are reasonable 
folks, but they do hold the final word.

I promised Scott that I'd wait until today to let folks that have 
been out of the office over the past two weeks (plus a day to 
download all the pending mail) before prompting the group another 
time to consider this issue.

The crux of the issue is, there are situations in which a registrar 
may wish to alter the default privacy considerations for data when 
interacting with a registry.  Not all registrar-registry environments 
will need this flexibility, but there is a claim that some exist.  (I 
have no personal, first-hand knowledge of any such environments.)

How can we accomodate such environments?  That is the basic question.

The most recent thread on this begins with:
      http://www.cafax.se/ietf-provreg/maillist/2002-12/msg00100.html

Next: Milestones, ROID and other issues...
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h02Koq9p001526 for <[e-mail]>; Thu, 2 Jan 2003 21:50:52 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.5/8.12.5/Submit) id h02KopxX001525 for ietf-provreg-outgoing; Thu, 2 Jan 2003 21:50:51 +0100 (MET)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.5/8.12.5) with ESMTP id h02Kok9p001520 for <[e-mail]>; Thu, 2 Jan 2003 21:50:46 +0100 (MET)
Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by smtp1.arin.net (8.12.4/8.12.4) with ESMTP id h02KohYm018425; Thu, 2 Jan 2003 15:50:43 -0500 (EST)
Received: from [192.149.252.226] (localhost [127.0.0.1]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id PAA18878; Thu, 2 Jan 2003 15:50:42 -0500 (EST)
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0eba3a555ce66f@[192.149.252.226]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 2 Jan 2003 15:50:39 -0500
To: Joe Abley <[e-mail]>, "Hollenbeck, Scott" <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: Re: Updated (and hopefully the last) EPP Privacy Proposal
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

At 13:31 -0500 12/30/02, Joe Abley wrote:
>It might be worth mentioning that neither of these proposals touch the
>base EPP spec. I don't see how privacy concerns should stop the base EPP
>spec from proceeding, when it seems clear that their scope is limited to
>the object binding specifications which deal with data.

The crudest answer to this is that the IESG won't permit the 
documents to progress without addressing privacy concerns - whether 
or not the proposed solutions touch the base spec.  That is why we 
must address the problem.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          [phone]
ARIN Research Engineer