Subject: [ietf-provreg] Just checking ...

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 31 Jan 2003 20:02:00 -0500

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

Date: Fri, 31 Jan 2003 15:33:26 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] preparing a meeting slot request
Cc: Edward Lewis <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

To: Rick Wesson <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, Edward Lewis <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] preparing a meeting slot request 
Date: Fri, 31 Jan 2003 14:35:25 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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.

Date: Fri, 31 Jan 2003 11:24:22 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: Edward Lewis <[email-masked]>, <[email-masked]>
Subject: Re: [ietf-provreg] preparing a meeting slot request 
Sender: [email-masked]

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

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [ietf-provreg] preparing a meeting slot request 
Date: Fri, 31 Jan 2003 14:14:49 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 31 Jan 2003 13:25:16 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] preparing a meeting slot request
Cc: [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>
Cc: [email-masked]
Subject: RE: [ietf-provreg] provreg milestones
Date: Fri, 31 Jan 2003 11:49:25 -0500
Sender: [email-masked]

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

Date: Fri, 31 Jan 2003 11:28:23 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] provreg milestones
Cc: Edward Lewis <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-provreg] provreg milestones 
Date: Fri, 31 Jan 2003 10:55:09 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: [ietf-provreg] provreg milestones
Date: Fri, 31 Jan 2003 10:39:37 -0500
Sender: [email-masked]

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:[email-masked]]
> Sent: Friday, January 31, 2003 10:15 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> 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]

Date: Fri, 31 Jan 2003 10:14:40 -0500
To: [email-masked], [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] provreg milestones
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-08.txt
Date: Fri, 31 Jan 2003 07:44:16 -0500
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 30, 2003 7:54 AM
> To: IETF-Announce; @cafax.se
> Cc: [email-masked]
> 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.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-tcp-06.txt
Date: Thu, 30 Jan 2003 07:54:42 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-host-06.txt
Date: Thu, 30 Jan 2003 07:54:37 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-domain-06.txt
Date: Thu, 30 Jan 2003 07:54:31 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-contact-06.txt
Date: Thu, 30 Jan 2003 07:54:26 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-08.txt
Date: Thu, 30 Jan 2003 07:54:21 -0500
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Subject: RE: [ietf-provreg] draft's expiring
Date: Fri, 24 Jan 2003 15:13:21 -0500
Sender: [email-masked]

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

Date: Fri, 24 Jan 2003 14:22:41 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] draft's expiring
Cc: [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

To: Edward Lewis <[email-masked]>
cc: Vittorio Bertola <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] where are we with privacy 
Date: Thu, 23 Jan 2003 16:06:05 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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)

Date: Thu, 23 Jan 2003 11:06:16 -0500
To: Vittorio Bertola <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: [ietf-provreg] where are we with privacy
Cc: Edward Lewis <[email-masked]>, [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

To: Vittorio Bertola <[email-masked]>
cc: Edward Lewis <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] where are we with privacy 
Date: Thu, 23 Jan 2003 07:15:40 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

From: Vittorio Bertola <[email-masked]>
To: Edward Lewis <[email-masked]>
Cc: [email-masked]
Subject: Re: [ietf-provreg] where are we with privacy
Date: Thu, 23 Jan 2003 10:42:36 +0100
Sender: [email-masked]

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

To: Edward Lewis <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] where are we with privacy 
Date: Tue, 21 Jan 2003 19:48:51 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> 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

To: Eric Brunner-Williams in Portland Maine <[email-masked]>
cc: Edward Lewis <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] where are we with privacy 
Date: Tue, 21 Jan 2003 18:14:42 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

opps. a dot de trops.

s/\.EU/EU/

sorry if anyone was confused.

eric
(who put the "dot" in dotty)

To: Edward Lewis <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [ietf-provreg] where are we with privacy 
Date: Tue, 21 Jan 2003 14:05:35 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> 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

Date: Tue, 21 Jan 2003 12:49:08 -0500
To: "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: [ietf-provreg] where are we with privacy
Cc: "'Edward Lewis'" <[email-masked]>, [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>
Cc: [email-masked]
Subject: RE: [ietf-provreg] where are we with privacy
Date: Tue, 21 Jan 2003 11:52:24 -0500
Sender: [email-masked]

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

Date: Tue, 21 Jan 2003 11:36:52 -0500
To: "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: [ietf-provreg] where are we with privacy
Cc: "'Edward Lewis'" <[email-masked]>, [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Subject: RE: [ietf-provreg] where are we with privacy
Date: Mon, 20 Jan 2003 08:49:36 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Edward Lewis [mailto:[email-masked]]
> Sent: Sunday, January 19, 2003 9:00 PM
> To: [email-masked]
> Cc: [email-masked]
> 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-

Date: Sun, 19 Jan 2003 21:00:15 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] where are we with privacy
Cc: [email-masked]
Sender: [email-masked]

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

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

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

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

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

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

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

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

To: Vittorio Bertola <[email-masked]>
cc: [email-masked], [email-masked]
Subject: [ietf-provreg] Re: An user's point of view on the privacy issue 
Date: Sat, 18 Jan 2003 08:25:46 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> 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

To: Edward Lewis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: [ietf-provreg] Re: document management
Date: Fri, 17 Jan 2003 17:21:42 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> 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

Reply-To: <[email-masked]>
From: "Ross Wm. Rader" <[email-masked]>
To: <[email-masked]>, "'Michael Young'" <[email-masked]>, "'Vittorio Bertola'" <[email-masked]>, <[email-masked]>
Subject: RE: An user's point of view on the privacy issue
Date: Fri, 17 Jan 2003 12:01:31 -0500
Organization: Tucows Inc.
Importance: Normal
Sender: [email-masked]

> 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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ross Wm. Rader
> Sent: Friday, January 17, 2003 9:46 AM
> To: 'Michael Young'; 'Vittorio Bertola'; [email-masked]
> 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: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Michael Young
> > Sent: Friday, January 17, 2003 8:49 AM
> > To: 'Vittorio Bertola'; [email-masked]
> > 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: [email-masked] 
> [mailto:[email-masked]]
> > On Behalf Of Vittorio Bertola
> > Sent: January 17, 2003 5:03 AM
> > To: [email-masked]
> > 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/ <-----------------------
> > 
> > 
> 

Reply-To: <[email-masked]>
From: "Ross Wm. Rader" <[email-masked]>
To: "'Michael Young'" <[email-masked]>, "'Vittorio Bertola'" <[email-masked]>, <[email-masked]>
Subject: RE: An user's point of view on the privacy issue
Date: Fri, 17 Jan 2003 09:45:40 -0500
Organization: Tucows Inc.
Importance: Normal
Sender: [email-masked]

> 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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Young
> Sent: Friday, January 17, 2003 8:49 AM
> To: 'Vittorio Bertola'; [email-masked]
> 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: [email-masked] [mailto:[email-masked]]
> On Behalf Of Vittorio Bertola
> Sent: January 17, 2003 5:03 AM
> To: [email-masked]
> 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/ <-----------------------
> 
> 

From: "Michael Young" <[email-masked]>
To: "'Vittorio Bertola'" <[email-masked]>, <[email-masked]>
Subject: RE: An user's point of view on the privacy issue
Date: Fri, 17 Jan 2003 08:48:49 -0500
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Vittorio Bertola
Sent: January 17, 2003 5:03 AM
To: [email-masked]
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/ <-----------------------

From: Vittorio Bertola <[email-masked]>
To: [email-masked]
Subject: An user's point of view on the privacy issue
Date: Fri, 17 Jan 2003 11:03:26 +0100
Sender: [email-masked]

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: 56th IETF WG/BOF Scheduling
Date: Tue, 14 Jan 2003 10:36:54 -0500
Sender: [email-masked]

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

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Joe Abley'" <[email-masked]>, "'Edward Lewis'" <[email-masked]>, [email-masked]
Subject: Re: privacy 
Date: Fri, 10 Jan 2003 13:43:22 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    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

To: Randy Bush <[email-masked]>
cc: Joe Abley <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: privacy 
Date: Thu, 09 Jan 2003 14:57:07 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

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

Date: Thu, 9 Jan 2003 10:46:57 -0800 (PST)
Reply-To: Karl Auerbach <[email-masked]>
To: [email-masked], Rick Wesson <[email-masked]>, <[email-masked]>
cc: Richard Shockey <[email-masked]>, Stephane Bortzmeyer <[email-masked]>, Edward Lewis <[email-masked]>
Subject: Re: privacy
From: Karl Auerbach <[email-masked]>
Sender: [email-masked]

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: document management
Date: Thu, 9 Jan 2003 13:26:24 -0500 
Sender: [email-masked]

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

Date: Thu, 9 Jan 2003 13:16:21 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Fwd: 56th IETF WG/BOF Scheduling
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

Date: Thu, 9 Jan 2003 12:54:02 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: privacy
Mail-Followup-To: Andrew Sullivan <[email-masked]>, [email-masked]
Sender: [email-masked]

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
<[email-masked]>                              M2P 2A8
                                         +1 416 646 3304 x110

Date: Thu, 9 Jan 2003 10:55:37 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>, Edward Lewis <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: document management
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: document management 
Date: Thu, 09 Jan 2003 10:48:37 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> 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

Date: Thu, 9 Jan 2003 10:06:57 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: document management
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

From: Randy Bush <[email-masked]>
To: Joe Abley <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: privacy
Date: Thu, 09 Jan 2003 04:38:08 -0800
Sender: [email-masked]

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

Date: Thu, 9 Jan 2003 07:32:41 -0500
Subject: Re: privacy
Cc: "Paul M. Kane" <[email-masked]>, [email-masked], [email-masked]
To: Randy Bush <[email-masked]>
From: Joe Abley <[email-masked]>
Sender: [email-masked]

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

Date: Thu, 9 Jan 2003 13:06:26 +0100 (CET)
From: =?iso-8859-1?Q?Eva_Steng=E5rd?= <[email-masked]>
To: Randy Bush <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: privacy
Sender: [email-masked]

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
> 

From: Randy Bush <[email-masked]>
To: "Paul M. Kane" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: privacy
Date: Thu, 09 Jan 2003 03:43:20 -0800
Sender: [email-masked]

> 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

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Edward Lewis'" <[email-masked]>, [email-masked]
Subject: Re: privacy 
Date: Thu, 09 Jan 2003 12:12:52 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    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

To: Rick Wesson <[email-masked]>
cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: privacy 
Date: Wed, 08 Jan 2003 19:37:02 -0800
From: Allison Mankin <[email-masked]>
Sender: [email-masked]

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

To: Rick Wesson <[email-masked]>
cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>, Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: privacy 
Date: Wed, 08 Jan 2003 19:22:36 -0800
From: Allison Mankin <[email-masked]>
Sender: [email-masked]

Rick,

From: Randy Bush <[email-masked]>
To: Rick Wesson <[email-masked]>
Cc: Richard Shockey <[email-masked]>, Stephane Bortzmeyer <[email-masked]>, Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: Re: privacy
Date: Wed, 08 Jan 2003 13:15:22 -0800
Sender: [email-masked]

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

From: Randy Bush <[email-masked]>
To: Richard Shockey <[email-masked]>
Cc: Stephane Bortzmeyer <[email-masked]>, Rick Wesson <[email-masked]>, Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: privacy
Date: Wed, 08 Jan 2003 12:40:56 -0800
Sender: [email-masked]

> 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

To: Edward Lewis <[email-masked]>
cc: [email-masked]
Subject: Re: mail list traffic 
Date: Thu, 09 Jan 2003 10:54:39 +0100
From: Jaap Akkerhuis <[email-masked]>
Sender: [email-masked]

    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

Date: Thu, 09 Jan 2003 09:10:36 +0000
From: "Paul M. Kane" <[email-masked]>
To: Randy Bush <[email-masked]>
CC: Rick Wesson <[email-masked]>, Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: privacy
Sender: [email-masked]

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

Date: Wed, 08 Jan 2003 12:52:31 -0500
To: Stephane Bortzmeyer <[email-masked]>, Rick Wesson <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: Re: privacy
Cc: Randy Bush <[email-masked]>, Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 05:50 PM 1/8/2003 +0100, Stephane Bortzmeyer wrote:
>On Wed, Jan 08, 2003 at 08:29:29AM -0800,
>  Rick Wesson <[email-masked]> 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 <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Cc: "w3c-P3P-specification@w3. Org" <[email-masked]>,
    [email-masked]
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:[email-masked]?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              <[email-masked]>
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: +1 815.333.1237
<mailto:[email-masked]> or <mailto:[email-masked]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

From: Randy Bush <[email-masked]>
To: Rick Wesson <[email-masked]>
Cc: Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: Re: privacy
Date: Wed, 08 Jan 2003 09:23:03 -0800
Sender: [email-masked]

> 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

To: [email-masked]
Subject: Re: privacy
Date: Wed, 08 Jan 2003 18:18:58 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> 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

Date: Wed, 8 Jan 2003 16:42:34 -0500
Subject: Re: privacy
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
To: Edward Lewis <[email-masked]>
From: Joe Abley <[email-masked]>
Sender: [email-masked]

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

Date: Wed, 8 Jan 2003 16:38:09 -0500
To: Joe Abley <[email-masked]>, Edward Lewis <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: privacy
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

Date: Wed, 8 Jan 2003 16:21:59 -0500
Subject: Re: privacy
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
To: Edward Lewis <[email-masked]>
From: Joe Abley <[email-masked]>
Sender: [email-masked]

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

Date: Wed, 8 Jan 2003 16:11:52 -0500
To: Joe Abley <[email-masked]>, Edward Lewis <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: privacy
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

Date: Wed, 8 Jan 2003 16:08:53 -0500
To: Randy Bush <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: privacy
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

Date: Wed, 8 Jan 2003 16:08:08 -0500
Subject: Re: privacy
Cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked]
To: Edward Lewis <[email-masked]>
From: Joe Abley <[email-masked]>
Sender: [email-masked]

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

Date: Wed, 8 Jan 2003 12:58:50 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Randy Bush <[email-masked]>
cc: Richard Shockey <[email-masked]>, Stephane Bortzmeyer <[email-masked]>, Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: Re: privacy
Sender: [email-masked]

> 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

Date: Wed, 8 Jan 2003 15:53:29 -0500
To: Joe Abley <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: privacy
Cc: "'Edward Lewis'" <[email-masked]>, [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

Date: Wed, 08 Jan 2003 14:13:20 -0500
To: Stephane Bortzmeyer <[email-masked]>, Rick Wesson <[email-masked]>
From: Richard Shockey <[email-masked]>
Subject: Re: privacy
Cc: Randy Bush <[email-masked]>, Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Sender: [email-masked]

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 <[email-masked]> 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 <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Cc: "w3c-P3P-specification@w3. Org" <[email-masked]>,
    [email-masked]
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:[email-masked]?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              <[email-masked]>
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: +1 815.333.1237
<mailto:[email-masked]> or <mailto:[email-masked]>
  <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Date: Wed, 8 Jan 2003 20:09:48 +0100
Subject: Re: privacy
Cc: Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, <[email-masked]>
To: Rick Wesson <[email-masked]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Sender: [email-masked]

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

Date: Wed, 8 Jan 2003 13:51:58 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: mail list traffic
Cc: [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

Date: Wed, 8 Jan 2003 13:49:45 -0500
To: Stephane Bortzmeyer <[email-masked]>, Rick Wesson <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: privacy
Cc: Randy Bush <[email-masked]>, Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

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 <[email-masked]> 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                                          +1-703-227-9854
ARIN Research Engineer

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Joe Abley'" <[email-masked]>
Cc: "'Edward Lewis'" <[email-masked]>, [email-masked]
Subject: RE: privacy
Date: Wed, 8 Jan 2003 12:47:24 -0500 
Sender: [email-masked]

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

Date: Wed, 8 Jan 2003 09:35:27 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
cc: Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: Re: privacy
Sender: [email-masked]

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

Date: Wed, 8 Jan 2003 12:33:36 -0500
Subject: Re: privacy
Cc: "'Edward Lewis'" <[email-masked]>, [email-masked]
To: "Hollenbeck, Scott" <[email-masked]>
From: Joe Abley <[email-masked]>
Sender: [email-masked]

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

Date: Wed, 08 Jan 2003 12:32:56 -0500
From: Andrew Newton <[email-masked]>
To: Rick Wesson <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: privacy
Sender: [email-masked]

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Joe Abley'" <[email-masked]>
Cc: "'Edward Lewis'" <[email-masked]>, [email-masked]
Subject: RE: privacy
Date: Wed, 8 Jan 2003 12:21:21 -0500 
Sender: [email-masked]

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

Date: Wed, 8 Jan 2003 17:50:17 +0100
From: Stephane Bortzmeyer <[email-masked]>
To: Rick Wesson <[email-masked]>
Cc: Randy Bush <[email-masked]>, Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: privacy
Organization: NIC France
Sender: [email-masked]

On Wed, Jan 08, 2003 at 08:29:29AM -0800,
 Rick Wesson <[email-masked]> 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.

Date: Wed, 8 Jan 2003 08:29:29 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Randy Bush <[email-masked]>
cc: Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, <[email-masked]>
Subject: Re: privacy
Sender: [email-masked]

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

Date: Wed, 8 Jan 2003 11:15:22 -0500
Subject: Re: privacy
Cc: "'Edward Lewis'" <[email-masked]>, [email-masked]
To: "Hollenbeck, Scott" <[email-masked]>
From: Joe Abley <[email-masked]>
Sender: [email-masked]

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

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Edward Lewis'" <[email-masked]>, [email-masked]
Subject: RE: privacy
Date: Wed, 8 Jan 2003 07:17:41 -0500 
Sender: [email-masked]

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

From: "McGarry, Tom" <[email-masked]>
To: =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: Edward Lewis <[email-masked]>
Subject: RE: privacy
Date: Tue, 7 Jan 2003 18:12:34 -0500 
Sender: [email-masked]

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:[email-masked]]
Sent: Tuesday, January 07, 2003 5:29 PM
To: Rick Wesson
Cc: Edward Lewis; [email-masked]'; [email-masked]; [email-masked]
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                                          +1-703-227-9854
>> ARIN Research Engineer
>>
>

Date: Tue, 7 Jan 2003 23:28:40 +0100
Subject: Re: privacy
Cc: Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, <[email-masked]>, <[email-masked]>
To: Rick Wesson <[email-masked]>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
Sender: [email-masked]

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                                          +1-703-227-9854
>> ARIN Research Engineer
>>
>

Date: Tue, 7 Jan 2003 17:04:25 -0500
To: Rick Wesson <[email-masked]>, Edward Lewis <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: privacy
Cc: "[email-masked]'" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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.:
    ([email-masked] 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                                          +1-703-227-9854
ARIN Research Engineer

Date: Tue, 7 Jan 2003 13:43:57 -0800 (PST)
From: Rick Wesson <[email-masked]>
To: Edward Lewis <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: privacy
Sender: [email-masked]

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                                          +1-703-227-9854
> ARIN Research Engineer
>

Date: Tue, 7 Jan 2003 14:40:21 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: privacy
Cc: [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer

Date: Thu, 2 Jan 2003 15:50:39 -0500
To: Joe Abley <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Updated (and hopefully the last) EPP Privacy Proposal
Cc: [email-masked]
Sender: [email-masked]

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                                          +1-703-227-9854
ARIN Research Engineer