Subject: Minneapolis
From: Edward Lewis <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 31 Jan 2002 08:52:37 -0500

FYI, Since I last sent a message, I've submitted a request for a 2-hour
time slot in Minneapolis.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

Date: 29 Jan 2002 14:05:13 -0000
From: [email-masked]
To: [email-masked]
Subject: RE: EPP Document Last Call Issue Summary
Sender: [email-masked]

Hi,

perhaps stating the obvious here, but I think the way it is being done in 
06/04 is very good as it (as Scott mentions) gives the RegistrY the choice 
on what policy to use. And the RegistrY can also easily change their policy 
later without having to think about protocol compatibility...

Asbjorn

On Fri, 25 Jan 2002 12:08:38 -0500 "Hollenbeck, Scott" wrote:
>> -----Original Message-----
>> From: Rick H Wesson [mailto:[email-masked]]
>> I believe that the vast majority of registrars requested the ability
>> to view domains. This viewpoint was overwhelmingly expressed 
>> to VGRS at a
>> Registry meeting before the November ICANN meetings.
>> 
>> I feel that this change is not what the vast majority of registry and
>> registrars asked for but supports a position of VGRS.
>
>Comments from other folks on the provreg list supported the change.  As-is,
>what's in the draft now allows server operators (not just VeriSign) to set
>their own policies -- I strongly believe that's the most reasonable
>approach.

-- 
 The information transmitted in this email is intended only for the person(s)
 or entity to which it is addressed and may contain proprietary, confidential
 and/or privileged material. If you have received this email in error, please
 contact the sender by replying and delete this email so that it is not
 recoverable. If you are not the intended recipient(s), any retention, review,
 disclosure, distribution, copying, printing, dissemination, or other use of,
 or taking of any action in reliance upon, this information is strictly
 prohibited and without liability on our part.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: EPP Schema and Example Files
Date: Fri, 25 Jan 2002 15:46:00 -0500
Sender: [email-masked]

Compressed archives containing the EPP-06 schema and example files can be
found here:

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

and here:

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

-Scott- 

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Rick H Wesson'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, Registrars List <[email-masked]>
Subject: RE: EPP Document Last Call Issue Summary
Date: Fri, 25 Jan 2002 12:08:38 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Rick H Wesson [mailto:[email-masked]]
> Sent: Friday, January 25, 2002 11:50 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]'; Registrars List
> Subject: Re: EPP Document Last Call Issue Summary
> 
> Scott,
> 
> considerable last-minute changes.

Everything significant was discussed on the list.

> The one below so significantly changes how registries and 
> registrars have
> operated in the past I must disagree with this change until we have a
> much wider discussion of how the <info> command is to work.
> 
> I believe that the vast majority of registrars requested the ability
> to view domains. This viewpoint was overwhelmingly expressed 
> to VGRS at a
> Registry meeting before the November ICANN meetings.
> 
> I feel that this change is not what the vast majority of registry and
> registrars asked for but supports a position of VGRS.

Rick,

I posted the compromise position implemented in the draft twice (once at
your specific request [1], [2]), and you didn't object to it until now.
Comments from other folks on the provreg list supported the change.  As-is,
what's in the draft now allows server operators (not just VeriSign) to set
their own policies -- I strongly believe that's the most reasonable
approach.

Plus, I conferred with the VeriSign folks who attended the meeting you
referred to.  Per them, the significant ask was to be able to see domain
details in the context of ransfers.  The updated document allows a client to
see full domain details in that context without exception.

-Scott-

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

[2]
http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00064.html

Date: Fri, 25 Jan 2002 08:49:39 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, Registrars List <[email-masked]>
Subject: Re: EPP Document Last Call Issue Summary
Sender: [email-masked]

Scott,

considerable last-minute changes.

The one below so significantly changes how registries and registrars have
operated in the past I must disagree with this change until we have a
much wider discussion of how the <info> command is to work.

I believe that the vast majority of registrars requested the ability
to view domains. This viewpoint was overwhelmingly expressed to VGRS at a
Registry meeting before the November ICANN meetings.

I feel that this change is not what the vast majority of registry and
registrars asked for but supports a position of VGRS.

-rick

On Fri, 25 Jan 2002, Hollenbeck, Scott wrote:

> http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00022.html
> <authInfo> use with <info> command; compromise implemented.  Security
> considerations updated in the domain and contact mappings.
>

To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: EPP Document Last Call Issue Summary 
Date: Fri, 25 Jan 2002 09:07:51 -0800
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott,

My complements on seeing this through from BoF to core document WG Last Call.

Eric

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: EPP Document Last Call Issue Summary
Date: Fri, 25 Jan 2002 08:47:19 -0500
Sender: [email-masked]

The EPP document set has been updated to address comments received during
and after the WG last call period.  This is a summary of the comments
received and how they were addressed in the new documents.  Here's a link to
the last call announcement:

http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00037.html

The description below will note comments that resulted in document changes.
Please see the "Revisions" section of each document for pointers to the
specific document sections that were changed as a result of implementing the
changes.  On to the comments in the order they were received...

http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00038.html
All implemented except for "Adding elements to the domain mapping to support
delegation to hosts that do not or should not need to exist as host objects"
and "make the <msg> element OPTIONAL in the <result> element".  Discussion
around both of these suggestions led in different directions.  Text was
added to the domain mapping document to describe external host handling, and
there were objections to the <msg> element suggestion.

http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00041.html
Fix to the ROID pattern; implemented.

http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00043.html
Adding <authInfo> to the <transfer> query command; implemented.

http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00002.html
Replacement of references to ISO documents where possible; implemented.

http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00012.html
Change to the way internationalized and localized contact postal info is
exchanged; implemented.

http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00014.html
Text fix in <check> command description; implemented.

http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00016.html
Data collection policy changes; implemented.  Poll response format changes;
implemented.  Content length header in TCP transport; implemented.  Contact
transfers related to domain transfers; nothing done as there was no
agreement on there even being an issue.

http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00018.html
External host description and processing requirements; implemented.

http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00030.html
Empty text element processing; implemented.

http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00041.html
"type" attribute in <poll> response; not implemented as subsequent
discussion described already-present alternatives.

http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00022.html
<authInfo> use with <info> command; compromise implemented.  Security
considerations updated in the domain and contact mappings.

http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00036.html
MX record provisioning; taken off-list for later action.  For those who
wanted to follow this, it hasn't gone anywhere yet.

http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00067.html
Notification assertions; implemented.

Other cross-document changes made as a result of proofreading:

Fixed typos, separated references into normative and informative sections,
changes to "must", "may" etc. to avoid confusion with RFC 2119 directives.

Core protocol proofreading fixes:

Fixed a schema error that limited <extension> child elements to a single
extension, and fixed another schema error that limited version numbers to
single digits.

Contact mapping proofreading fixes:

Changed type of email and telephone number types to "token" from
"normalizedString" since these values should never contain certain
acceptable normalizedString characters.

Domain mapping proofreading fixes:

Fixed <info> and <renew> response descriptions to note that the <exDate>
element is (and has been) OPTIONAL per the schema.  Minor text change in
section 2.3 to avoid use of the term "zone" when describing clientHold and
serverHold status.

Host mapping proofreading fixes:

Added text to section 2.5 to reinforce that IP addresses aren't always
required when a host is provisioned for use as a DNS name server.  Updated
IPv6 address references.

-Scott- 

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-epp-tcp-04.txt
Date: Fri, 25 Jan 2002 06:53:23 -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-04.txt
	Pages		: 10
	Date		: 24-Jan-02
	
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-04.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-04.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-04.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-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-tcp-04.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: I-D ACTION:draft-ietf-provreg-epp-host-04.txt
Date: Fri, 25 Jan 2002 06:53:18 -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-04.txt
	Pages		: 29
	Date		: 24-Jan-02
	
This document describes an Extensible Provisioning Protocol (EPP) map-
ping 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-04.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-04.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-04.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-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-host-04.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: I-D ACTION:draft-ietf-provreg-epp-domain-04.txt
Date: Fri, 25 Jan 2002 06:53:13 -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-04.txt
	Pages		: 42
	Date		: 24-Jan-02
	
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-04.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-04.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-04.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-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-domain-04.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: I-D ACTION:draft-ietf-provreg-epp-contact-04.txt
Date: Fri, 25 Jan 2002 06:53:07 -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-04.txt
	Pages		: 39
	Date		: 24-Jan-02
	
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-04.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-04.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-04.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-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-provreg-epp-contact-04.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: I-D ACTION:draft-ietf-provreg-epp-06.txt
Date: Fri, 25 Jan 2002 06:53:02 -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-06.txt
	Pages		: 76
	Date		: 24-Jan-02
	
This document describes an application layer client-server protocol
for the provisioning and management of objects stored in a shared cen-
tral 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-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-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-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-06.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 24 Jan 2002 17:07:40 -0500
From: Daniel Manley <[email-masked]>
To: [email-masked]
Subject: Re: They're already calling for 53rd IETF Meetings
Sender: [email-masked]

Perhaps longer than one hour.  In SLC, it seemed like we had to rush 
through without being able to bring some topics to a reasonable 
conclusion.  I think we also started a little late and the next group 
didn't give us any spare time.

Dan

Hollenbeck, Scott wrote:

>>-----Original Message-----
>>From: Edward Lewis [mailto:[email-masked]]
>>Sent: Tuesday, January 22, 2002 4:56 PM
>>To: Eric Brunner-Williams in Portland Maine
>>Cc: Edward Lewis; [email-masked]; [email-masked]
>>Subject: Re: They're already calling for 53rd IETF Meetings
>>
>>
>>At 7:37 PM -0500 1/17/02, Eric Brunner-Williams in Portland 
>>Maine wrote:
>>
>>>In my opinion, a time slot in Minneapolis would be time well spent.
>>>
>>Does anyone else feel the need for a meeting?  I am not 
>>disputing Eric's
>>reasons, but I'd like to hear from a wider set of people.
>>
>>Are folks holding off a decision until they see new (already promised)
>>drafts and/or versions?
>>
>
>I intend to send the updated documents to the I-D administrator some time
>tomorrow.  Assuming no one finds that I did anything stupid or counter to
>what we've covered in the last call, I believe that the documents are ready
>to be sent to the IESG.  It would be nice if they could be last-called by
>the IESG prior to the March meeting, and if that happens we might have some
>additional topics for discussion.
>
>I'd prefer to see a more thorough description of Eric's suggested topics
>sent to the mailing list before rendering an opinion on their suitability as
>agenda items.  We might be able to have a more thoughtful discussion if we
>have something to look at ahead of time.
>
>Anyway, it sounds like it might be wise to reserve a meeting slot just to be
>on the safe side.
>
>-Scott-
>

From: "Hollenbeck, Scott" <[email-masked]>
To: [email-masked]
Subject: RE: They're already calling for 53rd IETF Meetings
Date: Wed, 23 Jan 2002 11:34:04 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Edward Lewis [mailto:[email-masked]]
> Sent: Tuesday, January 22, 2002 4:56 PM
> To: Eric Brunner-Williams in Portland Maine
> Cc: Edward Lewis; [email-masked]; [email-masked]
> Subject: Re: They're already calling for 53rd IETF Meetings
> 
> 
> At 7:37 PM -0500 1/17/02, Eric Brunner-Williams in Portland 
> Maine wrote:
> >In my opinion, a time slot in Minneapolis would be time well spent.
> 
> Does anyone else feel the need for a meeting?  I am not 
> disputing Eric's
> reasons, but I'd like to hear from a wider set of people.
> 
> Are folks holding off a decision until they see new (already promised)
> drafts and/or versions?

I intend to send the updated documents to the I-D administrator some time
tomorrow.  Assuming no one finds that I did anything stupid or counter to
what we've covered in the last call, I believe that the documents are ready
to be sent to the IESG.  It would be nice if they could be last-called by
the IESG prior to the March meeting, and if that happens we might have some
additional topics for discussion.

I'd prefer to see a more thorough description of Eric's suggested topics
sent to the mailing list before rendering an opinion on their suitability as
agenda items.  We might be able to have a more thoughtful discussion if we
have something to look at ahead of time.

Anyway, it sounds like it might be wise to reserve a meeting slot just to be
on the safe side.

-Scott-

Date: Tue, 22 Jan 2002 16:55:47 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: They're already calling for 53rd IETF Meetings
Cc: Edward Lewis <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

At 7:37 PM -0500 1/17/02, Eric Brunner-Williams in Portland Maine wrote:
>In my opinion, a time slot in Minneapolis would be time well spent.

Does anyone else feel the need for a meeting?  I am not disputing Eric's
reasons, but I'd like to hear from a wider set of people.

Are folks holding off a decision until they see new (already promised)
drafts and/or versions?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

Date: Sat, 19 Jan 2002 16:09:44 -0500
From: Daniel Manley <[email-masked]>
To: [email-masked]
Subject: Re: <poll> and object changes (was authInfo in <info> commands)
Sender: [email-masked]

yes, well it seems that I've become a broken record...

http://www.cafax.se/ietf-provreg/maillist/2001-12/msg00041.html

sorry for the repeating.

Dan

Hollenbeck, Scott wrote:

>Dan,
>
>Text describing the notification needs you mentioned below is going into the
>next version of the documents.
>
>-Scott-
>
>>-----Original Message-----
>>From: Daniel Manley [mailto:[email-masked]]
>>Sent: Friday, January 18, 2002 10:53 PM
>>To: Ed Rahn
>>Cc: [email-masked]; [email-masked]
>>Subject: <poll> and object changes (was authInfo in <info> commands)
>>
>>
>>It's my philosophy (and perhaps this should go into the 
>>drafts) that an 
>>EPP registry should/must create a notification to sponsoring 
>>client of 
>>an object when that object is modified without that client's direct 
>>involvement.  So a domain registrar, for example, would be 
>>notified of 
>>changes in the status of a transfer initiated by the other 
>>registrar or 
>>by the registry's auto-approve/deny mechanisms.  Actually, the 
>>requesting registrar should also be notified if the transfer 
>>is denied 
>>by the losing registrar or auto-denied/approved by the registry.
>>
>>Other situations where a registry would notify a registrar of 
>>changes to 
>>objects it owns:  auto-renewals, object (domain) expiry, changes 
>>initiated by the registry's support staff, etc...
>>
>>this way, the owning registrar (with regular polling, or with 
>>pushing) 
>>can count on always being in the know of changes to its 
>>objects in the 
>>registry.
>>
>>Dan
>>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Daniel Manley'" <[email-masked]>
Cc: [email-masked]
Subject: RE: <poll> and object changes (was authInfo in <info> commands)
Date: Sat, 19 Jan 2002 09:12:16 -0500
Sender: [email-masked]

Dan,

Text describing the notification needs you mentioned below is going into the
next version of the documents.

-Scott-

> -----Original Message-----
> From: Daniel Manley [mailto:[email-masked]]
> Sent: Friday, January 18, 2002 10:53 PM
> To: Ed Rahn
> Cc: [email-masked]; [email-masked]
> Subject: <poll> and object changes (was authInfo in <info> commands)
> 
> 
> It's my philosophy (and perhaps this should go into the 
> drafts) that an 
> EPP registry should/must create a notification to sponsoring 
> client of 
> an object when that object is modified without that client's direct 
> involvement.  So a domain registrar, for example, would be 
> notified of 
> changes in the status of a transfer initiated by the other 
> registrar or 
> by the registry's auto-approve/deny mechanisms.  Actually, the 
> requesting registrar should also be notified if the transfer 
> is denied 
> by the losing registrar or auto-denied/approved by the registry.
> 
> Other situations where a registry would notify a registrar of 
> changes to 
> objects it owns:  auto-renewals, object (domain) expiry, changes 
> initiated by the registry's support staff, etc...
> 
> this way, the owning registrar (with regular polling, or with 
> pushing) 
> can count on always being in the know of changes to its 
> objects in the 
> registry.
> 
> Dan

Date: Fri, 18 Jan 2002 20:11:00 -0800
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Filtering for content
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 06:57 PM 1/18/2002 -0800, Eric Brunner-Williams in Portland Maine wrote:
>We need to have Jim Fleming filtered (out) of the provreg list. TiA.

oh?  has he been posting to this list?

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

Date: Fri, 18 Jan 2002 23:13:58 -0500
From: Daniel Manley <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
CC: Edward Lewis <[email-masked]>, [email-masked]
Subject: Re: They're already calling for 53rd IETF Meetings
Sender: [email-masked]

Eric, I'm trying to find the reference you made to message on the 29th 
[of November?].  I've read messages from both you and Ed and don't see a 
mention of a single client.  Maybe I'm just missing it.  Can you send 
links to the specific message in archives or quote snippets?

Thanks,
Dan

Eric Brunner-Williams in Portland Maine wrote:

>Ed,
>
>In my opinion, a time slot in Minneapolis would be time well spent.
>
>I sent some suggestions to the chairs prior to SLC, one is in-progress as
>we speak -- the data protection (aka "privacy") bits, between Scott and I. 
>
>Other dohickies I suggested were:
>
>	1. "moving out of the ICANN gTLD ghetto
>                + adding the "sponsoring entity" authorization mechanism
>                + archival logging in-band (see <push>)
>	2. technical bells-and-whistles
>                + symmetric event model (see <push>)
>		+ bulk (ftp) model
>                + restart and recovery work
>	3. some unspecified security "stuff"
>
>Scott's suggestion that we put an Open Source server out is a good idea,
>and there has been real off-list and on-list interest in that. This is a
>good subject for at least 15 minutes.
>
>Another subject that is "ripe" now is the question of one client. Please
>see Ed's note of the 29th, and my reply, also of the 29th. This is a good
>subject for at least another 15 minutes.
>
>I'm implementing, and I'll be happy to attempt interoperability testing
>with nearly anyone prior to or during the week of -53.
>
>So, IMO, at least an hour, two would be fine if implementors reports are
>tossed in.
>
>Eric
>wampumpeag, llc
>

Date: Fri, 18 Jan 2002 22:53:11 -0500
From: Daniel Manley <[email-masked]>
To: Ed Rahn <[email-masked]>
CC: [email-masked], [email-masked]
Subject: <poll> and object changes (was authInfo in <info> commands)
Sender: [email-masked]

It's my philosophy (and perhaps this should go into the drafts) that an 
EPP registry should/must create a notification to sponsoring client of 
an object when that object is modified without that client's direct 
involvement.  So a domain registrar, for example, would be notified of 
changes in the status of a transfer initiated by the other registrar or 
by the registry's auto-approve/deny mechanisms.  Actually, the 
requesting registrar should also be notified if the transfer is denied 
by the losing registrar or auto-denied/approved by the registry.

Other situations where a registry would notify a registrar of changes to 
objects it owns:  auto-renewals, object (domain) expiry, changes 
initiated by the registry's support staff, etc...

this way, the owning registrar (with regular polling, or with pushing) 
can count on always being in the know of changes to its objects in the 
registry.

Dan

Ed Rahn wrote:

>
>If domain owners are able to make updates to domains through other
>registrars, would this information be given to the previous
>registrar, possible using poll.. Due to speed issues we keep most of our
>data local and do reconciliation when needed. This would cause out of sync
>information and make things a bit more complicated than needed.
>
>Ed Rahn
>ItsYourDomain.com
>

To: [email-masked]
cc: [email-masked]
Subject: Filtering for content
Date: Fri, 18 Jan 2002 18:57:45 -0800
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Liman,

We need to have Jim Fleming filtered (out) of the provreg list. TiA.

Eric

From: "Jim Fleming" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: http://www.dnso.org/clubpublic/ga-full/Arc09/msg00731.html
Date: Fri, 18 Jan 2002 14:32:59 -0800
Sender: [email-masked]

http://www.dnso.org/clubpublic/ga-full/Arc09/msg00731.html
a.. Subject: [ga] RE: [GTLD Registries List] FW: .BIZ Transfer Policy
a.. From: "Neuman, Jeff" <[email-masked]>
"We believe the mess in .com, .net and .org has taken way too long to
resolve and often the consumer is being left out of the debate."
...
"Before this can happen, however, registrars and registrants must be
educated on how to generate a token, how to maintain the security of a
token, and how to recover a lost token, through the EPP Protocol used by the
"thick registries."  This takes time."
-----

What is the "mess in .COM" ??

.COM is one of the "Best of Breed" TLDs that has made it past
the Proof-of-Concept phase. .BIZ and .US seem to be taking a
long time and are viewed by many to be a "mess".

2002 0:201 .COM
2002 1:158 .CLUB
2002 2:143 .FAMILY
2002 3:219 .INFO
2002 4:58 .LLC
2002 5:194 .INC
2002 6:171 .TV
2002 7:195 .CHURCH

How will EPP and all of this education about "tokens" help .COM ?

Will that be used for the new 2002 .COM servers ?...to support
mapping people's existing .COM nameservers into larger address spaces.

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.IPv8.info

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Rick H Wesson'" <[email-masked]>
Cc: [email-masked]
Subject: RE: <info> Command and authInfo
Date: Fri, 18 Jan 2002 07:14:35 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Rick H Wesson [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 8:26 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: RE: <info> Command and authInfo
> 
> 
> 
> Scott,
> 
> yes, I read those -- I was asking for the text in the draft, 
> to compare.
> 
> From what I understand the <info> command currently returns a 
> subset of
> the object depending or not if you are the sponsoring registrar.
> 
> Is this not waht passed last call?

No, that's NOT what passed last call.  The only field that is currently
explicitly identified as one that shouldn't be shown to anyone other than
the sponsoring client is the <authInfo> field.  Otherwise, the schema
defines the mandatory and optional fields, and those that are optional are
that way only because they may or may not exist.

The suggested compromise was to explicitly make more fields optional so that
they can be displayed (or not) based on a server's unauthorized client
policy.  That is:

- if you're the sponsoring client, you get it all.
- if you're not the sponsoring client, but you have the auth info, you get
it all.
- if you're not the sponsoring client and you don't have the auth info, you
get a subset defined by server policy.

This is derived from comments provided by Bruce and Jens-Uwe, so if I got it
wrong I hope one or both of them will correct me.

-Scott- 

Date: Thu, 17 Jan 2002 17:25:32 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: <[email-masked]>
Subject: RE: <info> Command and authInfo
Sender: [email-masked]

Scott,

yes, I read those -- I was asking for the text in the draft, to compare.

>From what I understand the <info> command currently returns a subset of
the object depending or not if you are the sponsoring registrar.

Is this not waht passed last call?

-rick

On Thu, 17 Jan 2002, Hollenbeck, Scott wrote:

> > -----Original Message-----
> > From: Rick H Wesson [mailto:[email-masked]]
> > Sent: Thursday, January 17, 2002 8:00 PM
> > To: Hollenbeck, Scott
> > Cc: 'Patrick'; [email-masked]
> > Subject: RE: <info> Command and authInfo
> >
>
> [snip]
>
> > Would you mind restating the compromise position -- I didn't
> > notice that
> > we had one. I've seen some objections to the current draft in
> > this are but
> > I don't understand what our compromise is; nor have I agreeded that we
> > have one.
>
> Look here:
> http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00031.html
>
> http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00033.html
>
> -Scott-
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Rick H Wesson'" <[email-masked]>
Cc: [email-masked]
Subject: RE: <info> Command and authInfo
Date: Thu, 17 Jan 2002 20:08:23 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Rick H Wesson [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 8:00 PM
> To: Hollenbeck, Scott
> Cc: 'Patrick'; [email-masked]
> Subject: RE: <info> Command and authInfo
> 

[snip]

> Would you mind restating the compromise position -- I didn't 
> notice that
> we had one. I've seen some objections to the current draft in 
> this are but
> I don't understand what our compromise is; nor have I agreeded that we
> have one.

Look here:
http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00031.html

http://www.cafax.se/ietf-provreg/maillist/2002-01/msg00033.html

-Scott-

Date: Thu, 17 Jan 2002 16:59:50 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Patrick'" <[email-masked]>, <[email-masked]>
Subject: RE: <info> Command and authInfo
Sender: [email-masked]

Scott,

On Thu, 17 Jan 2002, Hollenbeck, Scott wrote:

> > -----Original Message-----
> > From: Patrick [mailto:[email-masked]]
> > Sent: Thursday, January 17, 2002 5:30 PM
> > To: [email-masked]
> > Subject: Re: <info> Command and authInfo
> >
> >
> > But again, we shifted, my main point was having auth info used not
> > only for transfer but for other tasks. Or at least having the
> > _protocol_ not forbidding things, that a policy may wish to better
> > control.
>
> OK, here's my angst: we _had_ this in the protocol once before, and no one
> objected to changing things to where they are now.  If there's a strong
> desire to revisit that decision, I'd really like to see a lot more support
> for putting it back in before I spend the time putting text back in what I
> had to rip out last year.

We removed it once and there was vast agreement that it be removed, I have
not seen significant comments from impementors that it should be put back.

> So, I'd like to ask a basic question assuming that the compromise position
> on the <info> command has already been accepted:

Would you mind restating the compromise position -- I didn't notice that
we had one. I've seen some objections to the current draft in this are but
I don't understand what our compromise is; nor have I agreeded that we
have one.

> Should we put auth info back into the base protocol for possible use with
> any transform command or not?

no. There has not been a ground-swell for this simpley a single request,
which does not make consensus.

-rick

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Patrick'" <[email-masked]>, [email-masked]
Subject: RE: <info> Command and authInfo
Date: Thu, 17 Jan 2002 19:33:26 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Patrick [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 5:30 PM
> To: [email-masked]
> Subject: Re: <info> Command and authInfo
> 
> 
> But again, we shifted, my main point was having auth info used not
> only for transfer but for other tasks. Or at least having the
> _protocol_ not forbidding things, that a policy may wish to better
> control.

OK, here's my angst: we _had_ this in the protocol once before, and no one
objected to changing things to where they are now.  If there's a strong
desire to revisit that decision, I'd really like to see a lot more support
for putting it back in before I spend the time putting text back in what I
had to rip out last year.

So, I'd like to ask a basic question assuming that the compromise position
on the <info> command has already been accepted:

Should we put auth info back into the base protocol for possible use with
any transform command or not?

-Scott-

[1]
http://www.cafax.se/ietf-provreg/maillist/2001-04/msg00138.html

Date: Thu, 17 Jan 2002 17:58:07 -0500
To: <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: The mission of this mail list
Cc: [email-masked]
Sender: [email-masked]

This is a reminder that this mail list has been established for the
discussion of work undertaken by the Provisioning Registry Protocol
(provreg) working group of the IETF.  The charter of the group is found at
the following URL:
          http://www.ietf.org/html.charters/provreg-charter.html

We are engineering a particular provisioning protocol, discussing how it is
designed on this mail list.  Discussions regarding the legitimacy of any
participant in the use of the protocol, whether registrar, registry or
otherwise, is not within scope of this mail list.  Discussions regarding
the structure of the DNS data holdings and discussions regarding the
benefits of particular network-layer and transport-layer protocols are also
out of scope.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

Reply-To: "Ross Wm. Rader" <[email-masked]>
From: "Ross Wm. Rader" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: <info> Command and authInfo
Date: Thu, 17 Jan 2002 17:57:05 -0500
Organization: Tucows Inc.
Sender: [email-masked]

>
> I can't say I agree on this one. First of all, I don't think the registry
should ever deal directly with the customer, that's what registrars are for.
And if you have committed to a registrar, you should do the updates through
the same registrar, or transfer the name to another registrar.
>

As a registrar, I would have to agree with this, but on the other hand,
CIRA, for instance, would probably disagree. They've deployed a hybrid model
in which both the registry and the registrar maintain transactional contact
with the customer. While I mostly hate it, it strikes me that the
/good/bad/something of this nature/ concerning the model probably shouldn't
enter into a protocol discussion. On the other hand, supporting a structure
of this type might lead the wg down the path of including the kitchen sink
as well - clearly not the way to go. I submit that the wg should err on the
side of model inclusiveness and let the implementors make as many safe
decisions as possible about their respective businesses.

Anyways, this policy guy has said too much this year, I'll re-lurk now...'-)

-rwr

Date: Thu, 17 Jan 2002 23:30:02 +0100
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: <info> Command and authInfo
Organization: Gandi
Sender: [email-masked]

On Thu, Jan 17, 2002 at 05:15:13PM -0500, Hollenbeck, Scott took time to write:
> > Or the command was badely designed.
> > (it seems to me that if a Registry using EPP right now says that the
> > current state is not ok to do transfers... then it is not a social
> > problem of someone not willing to do something...)
> 
> I've already read the NeuLevel document, too, and I have to agree with Ross'
> assessment.  What was written wasn't an indictment of the protocol at all,
> but a description of a need for social education for a feature that hasn't
> been available before -- and that's probably a much more difficult task than
> this WG's task.

Only time will tell if transfers in EPP based/using auth info Registries are
faster/easier/better/whatever than in RRP based/not using auth info
Registries.

I think it will not, but this was not my main point.

I do not disagree that *now* education is the problem, just because
EPP is not known, and not used so much.
I still think however, than when this step will be achieved people
will realize that to do transfers they will need to do things extra
that they do not need to do now.
(asking the current Registrar to have access to the auth info to give
it to the new Registrar, which probably will not be able to rely only
on that, and will need to ask contacts or owner for approval, just
like now).

There are even cases of valid transfers that can be done now, that
will not be possible with this new scheme. Think of a domain name
``hijacked'' by whatever company being all contacts. If the *owner*
wish to do the transfer, right now a fax is a valid method of
approval, and the transfer can succed, whatever old contacts will do.
Now if auth info is required to do the transfer, and if this
information is only sent to contacts of the domain name, ...

The _idea_ of having the *owner* have control over things like that
is great. The idea that using an auth info resolves that is just not
correct in my eyes.

But again, we shifted, my main point was having auth info used not
only for transfer but for other tasks. Or at least having the
_protocol_ not forbidding things, that a policy may wish to better
control.

I just wanted to push Bruce last email, that's all ;-)
Building a protocol too restricted to current behaviors/gTLD
registries will lessen its use by others.
I guess it just depends if we want to replace RRP, or if we want to
replace *all* aims used right now by all Registries.

Patrick.

From: [email-masked]
To: [email-masked]
Date: Fri, 18 Jan 2002 05:39:30 +0700
Subject: RE: MX records in epp
Content-description: Mail message body
Sender: [email-masked]

On 17 Jan 2002 at 7:16, Hollenbeck, Scott wrote:

> > In the ".com.au" zone file we have MX records for some 
> > domains instead of NS
> > records.
> > 
> > e.g domainname.com.au   IN    MX 10    mailserver.com.au
> > 
> > How do you think this should be accommodated within EPP.?
...
> As Dave Crocker noted, the general provisioning case for MX records is
> within leaf-node zones.  If there are exceptions, like in .com.au, I'd
> suggest defining a protocol extension to the domain mapping to describe MX
> record provisioning.  Let's take it off-list if you'd like to explore that
> option.
...

Put me in that list.
We (.ID) domain has exactly the same thing as .AU.

Historically, we grew up in the .AU environment.
Our primary NS was actually physically located in
Australia and managed by friends there before
we moved it to Jakarta. ;-)

To be frankly, I didn't understand why we have 
that option. But, some people *do* use/utilize it.
(They don't need fancy web sites, just plain email.)

Regards
-- budi

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Patrick'" <[email-masked]>, [email-masked]
Subject: RE: <info> Command and authInfo
Date: Thu, 17 Jan 2002 17:15:13 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Patrick [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 3:50 PM
> To: [email-masked]
> Subject: Re: <info> Command and authInfo
> 
> 
> Or the command was badely designed.
> (it seems to me that if a Registry using EPP right now says that the
> current state is not ok to do transfers... then it is not a social
> problem of someone not willing to do something...)

I've already read the NeuLevel document, too, and I have to agree with Ross'
assessment.  What was written wasn't an indictment of the protocol at all,
but a description of a need for social education for a feature that hasn't
been available before -- and that's probably a much more difficult task than
this WG's task.

-Scott-

Date: Thu, 17 Jan 2002 17:07:38 -0600 (CST)
From: Ed Rahn <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: <info> Command and authInfo
Sender: [email-masked]

On 17 Jan 2002 [email-masked] wrote:

> On Thu, 17 Jan 2002 16:43:20 +0100 Patrick <[email-masked]> wrote:
> >IMNSHO auth info should enable someone having it to make
> >modifications (that is update at least, maybe delete and renew)
> >through any other ways (other Registrars, or even the Registry
> >directly). Protocols should make that possible, and then 
> >local policies should specify if it is to be used or not, and if yes,
> >how.
> 
> I can't say I agree on this one. First of all, I don't think the registry should ever deal directly with the customer, that's what registrars are for. And if you have committed to a registrar, you should do the updates through the same registrar, or transfer the name to another registrar.
> 
> Scenario: Registrar A is extremely cheap so I register my domain there, but registrar B has a great user interface for maintaining and modifying objects, so I use their interface instead of registrar a's. Registrar A will get my money, whereas registrar B has to do all the work for a "non-customer".
> 
> But what I might agree upon is that if you want to transfer a domain and have the authInfo, why should the losing registrar need to approve it? :-d
> 
> 
> Asbjorn
> Global Name Registry, Limited
> 
> -- 

If domain owners are able to make updates to domains through other
registrars, would this information be given to the previous
registrar, possible using poll.. Due to speed issues we keep most of our
data local and do reconciliation when needed. This would cause out of sync
information and make things a bit more complicated than needed.

Ed Rahn
ItsYourDomain.com

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: They're already calling for 53rd IETF Meetings 
Date: Thu, 17 Jan 2002 16:37:02 -0800
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed,

In my opinion, a time slot in Minneapolis would be time well spent.

I sent some suggestions to the chairs prior to SLC, one is in-progress as
we speak -- the data protection (aka "privacy") bits, between Scott and I. 

Other dohickies I suggested were:

	1. "moving out of the ICANN gTLD ghetto
                + adding the "sponsoring entity" authorization mechanism
                + archival logging in-band (see <push>)
	2. technical bells-and-whistles
                + symmetric event model (see <push>)
		+ bulk (ftp) model
                + restart and recovery work
	3. some unspecified security "stuff"

Scott's suggestion that we put an Open Source server out is a good idea,
and there has been real off-list and on-list interest in that. This is a
good subject for at least 15 minutes.

Another subject that is "ripe" now is the question of one client. Please
see Ed's note of the 29th, and my reply, also of the 29th. This is a good
subject for at least another 15 minutes.

I'm implementing, and I'll be happy to attempt interoperability testing
with nearly anyone prior to or during the week of -53.

So, IMO, at least an hour, two would be fine if implementors reports are
tossed in.

Eric
wampumpeag, llc

Reply-To: "Ross Wm. Rader" <[email-masked]>
From: "Ross Wm. Rader" <[email-masked]>
To: "Patrick" <[email-masked]>, <[email-masked]>
Subject: Re: <info> Command and authInfo
Date: Thu, 17 Jan 2002 16:31:47 -0500
Organization: Tucows Inc.
Sender: [email-masked]

>
> Or the command was badely designed.
> (it seems to me that if a Registry using EPP right now says that the
> current state is not ok to do transfers... then it is not a social
> problem of someone not willing to do something...)

Sounds pretty social to me...

"We also understand that many registrars are just now becoming familiar with
the capabilities and functionality of the "auth-info" tokens provided by the
so-called "thick registries" including .biz and .info.  However, overall
knowledge of the thick registry transfer process, particularly at the
Registrant level, is still minimal or non-existent.

Some of the problems that have come to our attention include (a) that some
Registrars are generating blanket (common) tokens for all domain name
registrants; (b) other registrars are not providing tokens to their
customers at all; (c) registrants are neither requesting tokens nor do
they have an adequate understanding about the need or use for tokens.
Finally, there do not yet exist secure and efficient systems for token
retrieval (re-issuance) in cases where a token is lost or stolen.

The net result is that few unique, secure and valid tokens are getting into
the hands of registrants, and hence to potential gaining Registrars. While
this is not the result of bad faith or bad practice by Registrars, it is
currently causing a gap in the education of the Registrar community and with
our ultimate consumers, the Registrants.  The industry and end-user
population have simply not been educated in the proper use of "auth-info"
tokens.   This is the fault and responsibility of NeuLevel as much as
anyone.  We feel that it is both our responsibility and obligation to ensure
that systems for the proper issue, storage and processing of tokens are
institutionalized within the industry.

...

Therefore, we intend to freeze .BIZ transfers for a period of 30 to 60 days
and engage in a
program of channel/user education regarding transfers with tokens. In this
program we will work with you to create systems and awareness for the issue,
storage and processing of secure, unique, valid tokens.  We do not believe
this is an insurmountable task.  We are at fault for not initiating it
sooner, and we want to advance this dialogue with you for the betterment of
our
industry practices and for the enhancement of the end-user experience."

-rwr

From: "Liu, Hong" <[email-masked]>
To: "'Hollenbeck, Scott'" <[email-masked]>, "'Bruce Tonkin'" <[email-masked]>
Cc: [email-masked]
Subject: RE: MX records in epp
Date: Thu, 17 Jan 2002 08:53:01 -0600
Sender: [email-masked]

Scott, Bruce,

Please also include me in this discussion. Thanks!

--Hong

Date: Thu, 17 Jan 2002 21:50:24 +0100
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: <info> Command and authInfo
Organization: Gandi
Sender: [email-masked]

On Thu, Jan 17, 2002 at 03:39:12PM -0500, Ross Wm. Rader took time to write:
> > Time will not change anything. auth_info for transfers just *adds*
> > another layer of complexity, and do not help _at all_.
> > If it was the contrary then why this last same week, both Afilias and
> > Neulevel sent an email to all Registrars, one explaining again what
> > the auth info is, the other saying that transfers will be blocked
> > because *current* (and they are using EPP...) state does not allow to
> > transfers without problems ?
> 
> <non-technical munge>
> Sorry to jump in here, but in the cases you describe above, the issue seems
> to be largely social - and could probably be extended to any command in the
> spec. If any party to the transaction induced by a command cannot/will
> not/does not exhibit behavior conducive to transaction completing, then the
> command will always be useless.
> </non-technical munge>

Or the command was badely designed.
(it seems to me that if a Registry using EPP right now says that the
current state is not ok to do transfers... then it is not a social
problem of someone not willing to do something...)

Transfers are specific because it involves 4 entities
(Registry, 2 Registrars, Registrant).
Other commands include only 3 (Registry, Registrar, Registrant).

Patrick.

Date: Thu, 17 Jan 2002 12:25:46 -0500
To: "Hollenbeck, Scott" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: MX records in epp
Cc: "'Bruce Tonkin'" <[email-masked]>, [email-masked]
Sender: [email-masked]

If this matures and folks involved are so motivated, I'd like to see this
come back to the list at some point.  I'd like to see if this fits under
the "E" in the protocol.  Not that I'm promising that this would be within
charter not am I inviting a WG document, but this may be an idea to explore.

At 7:16 AM -0500 1/17/02, Hollenbeck, Scott wrote:
>As Dave Crocker noted, the general provisioning case for MX records is
>within leaf-node zones.  If there are exceptions, like in .com.au, I'd
>suggest defining a protocol extension to the domain mapping to describe MX
>record provisioning.  Let's take it off-list if you'd like to explore that
>option.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

Date: Thu, 17 Jan 2002 12:40:14 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: They're already calling for 53rd IETF Meetings
Cc: [email-masked]
Sender: [email-masked]

Right now we are getting the requirements document back to the IESG.  (I
might add that I am optimistic that the wheels are in motion.)  Scott is
hammering out details of the drafts for which we have held a last call, so
any week now, we'll have those documents going to the IESG.  I feel that it
is important to progress those now so that implementations can mature more
rapidly in this quarter of the year.

We have a few other drafts under way.  There hasn't been much in the way of
activity over those documents - a least in mail list discussions.  Given
that and the need to produce implemenations:

   Do we need to have a time slot in Minneapolis?

Send in your opinion(s) and, if you think we need to meet, suggest an
annotated agenda item.

Also - if you are implementing, begin to consider how you might want to
participate in an interoperability test.

PS - As one of the chairs, I'm 50-50 on the need for a meeting.  But I'd
suggest one only if there is a need to have one.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

Reply-To: "Ross Wm. Rader" <[email-masked]>
From: "Ross Wm. Rader" <[email-masked]>
To: "Patrick" <[email-masked]>, <[email-masked]>
Subject: Re: <info> Command and authInfo
Date: Thu, 17 Jan 2002 15:39:12 -0500
Organization: Tucows Inc.
Sender: [email-masked]

> Time will not change anything. auth_info for transfers just *adds*
> another layer of complexity, and do not help _at all_.
> If it was the contrary then why this last same week, both Afilias and
> Neulevel sent an email to all Registrars, one explaining again what
> the auth info is, the other saying that transfers will be blocked
> because *current* (and they are using EPP...) state does not allow to
> transfers without problems ?

<non-technical munge>
Sorry to jump in here, but in the cases you describe above, the issue seems
to be largely social - and could probably be extended to any command in the
spec. If any party to the transaction induced by a command cannot/will
not/does not exhibit behavior conducive to transaction completing, then the
command will always be useless.
</non-technical munge>

-rwr

Date: Thu, 17 Jan 2002 21:04:15 +0100
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: <info> Command and authInfo
Organization: Gandi
Sender: [email-masked]

On Thu, Jan 17, 2002 at 10:53:13AM -0800, Rick H Wesson took time to write:
> > I agree with Bruce on this : the authinfo should have a bigger scope.
> >
> > Right now it is only for transfers (and thus should have been called
> > transfer auth or something like that, not auth info), and as we
> > already see it with some Registries using EPP, transfers are hard.
> 
> so transfers are hard with auth-info, thats what i expected, it may take
> some time for registrars and registrants to learn to deal with thisck
> registries and epp based ones.

My point is :
if we added auth_info to handle transfer, and to hope that this will
make transfers easier, I am sorry but the point is ALREADY missed,
and will be even more in the future.

This is fact and reality. This is unfortunate, I know.
On the paper, everything is great. In life, not so.

Time will not change anything. auth_info for transfers just *adds*
another layer of complexity, and do not help _at all_.
If it was the contrary then why this last same week, both Afilias and
Neulevel sent an email to all Registrars, one explaining again what
the auth info is, the other saying that transfers will be blocked
because *current* (and they are using EPP...) state does not allow to
transfers without problems ?

Thus, let at least make something useful to this concept of adding an
``authorisation'' at the domain layer (instead of at the contact
layer, like it is done so often).

> > IMNSHO auth info should enable someone having it to make
> > modifications (that is update at least, maybe delete and renew)
> > through any other ways (other Registrars, or even the Registry
> > directly). Protocols should make that possible, and then
> > local policies should specify if it is to be used or not, and if yes,
> > how.
> 
> 
> the consept is that auth-info aids in identifying an entity with
> authorization to transfer. The EPP mind-set is that the sponsoring
> registrar can updat their own objects; thus its the sponsoring registrar
> to authenticate not the registry except in the case of a transfer where by
> the gaining registrar authenticates with the registry by the use of the
> auth-info token.
> 
> This approch seems reasonable because it MUST be up to the sponsoring
> registrar to authenticate in this three-tear model. It mkaes the most
> sense from a client-server perspective too.

I am not saying this approach is never reasonable. I just say that
sometimes yes, sometimes not. Things should not be done so that it
can be the only option, otherwise EPP will never get used by more
than 5 Registries (the ``gTLD'' ones).

Patrick.

Date: Thu, 17 Jan 2002 20:58:39 +0100
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: <info> Command and authInfo
Organization: Gandi
Sender: [email-masked]

On Thu, Jan 17, 2002 at 05:53:07PM -0000, [email-masked] took time to write:
> On Thu, 17 Jan 2002 16:43:20 +0100 Patrick <[email-masked]> wrote:
> >IMNSHO auth info should enable someone having it to make
> >modifications (that is update at least, maybe delete and renew)
> >through any other ways (other Registrars, or even the Registry
> >directly). Protocols should make that possible, and then 
> >local policies should specify if it is to be used or not, and if yes,
> >how.
> 
> I can't say I agree on this one. First of all, I don't think the registry should ever deal directly with the customer, that's what registrars are for. And if you have committed to a registrar, you should do the updates through the same registrar, or transfer the name to another registrar.
> 
> Scenario: Registrar A is extremely cheap so I register my domain there, but registrar B has a great user interface for maintaining and modifying objects, so I use their interface instead of registrar a's. Registrar A will get my money, whereas registrar B has to do all the work for a "non-customer".

I misexplained myself.
I myself would not like that what I describe is possible. However I think this
is a policy problem, not a protocol on. Thus the protocol should
not be made so that this policy is not possible, if the Registry of a
given TLD chooses to do so.

There are Registries dealing with customers directly. .uk comes to my
mind.
The case of doing changes through a different Registrars might be
something very interesting when one Registrars fails or has so many
problems that it is not used anymore.
As for your example it is flawed, since Registrar B can totally ask
for a fee to change domain names handled by other REgistrar. Your
money problem disappear.

So my point is that we should take into account all models, and leave
place for all future ones. We should not do things as they are currently in
.COM/.NET/.ORG just because they are so.

If the true aim of this protocol is to be generic, and not to be just
a replacement of RRP, then it must not add constraints that may be
problems.

Patrick.

From: "Jim Fleming" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: <info> Command and authInfo 
Date: Thu, 17 Jan 2002 13:32:58 -0800
Sender: [email-masked]

The year is 2002...
The notion of a "gTLD" appears to be some out-dated concept
from the "toy", legacy, IPv4 Internet.

Registrar and Registry are artificial creations of multi-level-marketing
structures. It is not clear what the IETF has to do with marketing or
markets, etc. That would seem to be more of what one would find in
the EPP Trade Association.
http://sourceforge.net/projects/epp-ta/

As for 2002 TLDs....things are shaping up...
2002 0:201 .COM
2002 1:158 .CLUB
2002 2:143 .FAMILY
2002 3:219 .INFO
2002 4:58 .LLC
2002 5:194 .INC
2002 6:171 .TV
2002 7:195 .CHURCH

Jim Fleming
2002:[IPv4]:000X:03DB
http://www.IPv8.info

----- Original Message -----
From: "Eric Brunner-Williams in Portland Maine" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, January 17, 2002 1:12 PM
Subject: Re: <info> Command and authInfo

> Asbjorn,
>
> When a registrar fails, the "should" ceases to be controlling, as a "must"
> may arise. It is an edge case, but for EPP deployments outside of the gTLD
> market, the space of reasonable assumptions is larger, or less
constrained,
> than inside the gTLD market, and we have to solve for the larger problem.
>
> Eric
> wampumpeag, llc

Date: Thu, 17 Jan 2002 10:53:13 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: Patrick <[email-masked]>
cc: <[email-masked]>
Subject: Re: <info> Command and authInfo
Sender: [email-masked]

Patrick,

On Thu, 17 Jan 2002, Patrick wrote:

> On Tue, Jan 15, 2002 at 10:28:50AM -0500, Hollenbeck, Scott took time to write:
> > I'm not so sure of the benefit in putting <authInfo> into the <update>,
> > <delete> and <renew> commands given the discussion we had on the list some
> > time ago (we DID have it that way, and then folks wanted it removed from all
> > but <transfer>), but I understand what you're saying about the dates and the
> > <info> command.
>
> I agree with Bruce on this : the authinfo should have a bigger scope.
>
> Right now it is only for transfers (and thus should have been called
> transfer auth or something like that, not auth info), and as we
> already see it with some Registries using EPP, transfers are hard.

so transfers are hard with auth-info, thats what i expected, it may take
some time for registrars and registrants to learn to deal with thisck
registries and epp based ones.

> The auth info does not help anything regarding transfers.
> It just complicates things (current Registrar not giving it, and if
> the new Registrar already asks contacts for approval, the authinfo is
> of nouse... since it will be given to contacts, thus same problems in
> both case of hijacking and such).

> IMNSHO auth info should enable someone having it to make
> modifications (that is update at least, maybe delete and renew)
> through any other ways (other Registrars, or even the Registry
> directly). Protocols should make that possible, and then
> local policies should specify if it is to be used or not, and if yes,
> how.

the consept is that auth-info aids in identifying an entity with
authorization to transfer. The EPP mind-set is that the sponsoring
registrar can updat their own objects; thus its the sponsoring registrar
to authenticate not the registry except in the case of a transfer where by
the gaining registrar authenticates with the registry by the use of the
auth-info token.

This approch seems reasonable because it MUST be up to the sponsoring
registrar to authenticate in this three-tear model. It mkaes the most
sense from a client-server perspective too.

-rick

To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Re: <info> Command and authInfo 
Date: Thu, 17 Jan 2002 13:12:36 -0800
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Asbjorn,

When a registrar fails, the "should" ceases to be controlling, as a "must"
may arise. It is an edge case, but for EPP deployments outside of the gTLD
market, the space of reasonable assumptions is larger, or less constrained,
than inside the gTLD market, and we have to solve for the larger problem.

Eric
wampumpeag, llc

Date: 17 Jan 2002 17:53:07 -0000
From: [email-masked]
To: [email-masked]
Subject: Re: <info> Command and authInfo
Sender: [email-masked]

On Thu, 17 Jan 2002 16:43:20 +0100 Patrick <[email-masked]> wrote:
>IMNSHO auth info should enable someone having it to make
>modifications (that is update at least, maybe delete and renew)
>through any other ways (other Registrars, or even the Registry
>directly). Protocols should make that possible, and then 
>local policies should specify if it is to be used or not, and if yes,
>how.

I can't say I agree on this one. First of all, I don't think the registry should ever deal directly with the customer, that's what registrars are for. And if you have committed to a registrar, you should do the updates through the same registrar, or transfer the name to another registrar.

Scenario: Registrar A is extremely cheap so I register my domain there, but registrar B has a great user interface for maintaining and modifying objects, so I use their interface instead of registrar a's. Registrar A will get my money, whereas registrar B has to do all the work for a "non-customer".

But what I might agree upon is that if you want to transfer a domain and have the authInfo, why should the losing registrar need to approve it? :-d

Asbjorn
Global Name Registry, Limited

-- 
 The information transmitted in this email is intended only for the person(s)
 or entity to which it is addressed and may contain proprietary, confidential
 and/or privileged material. If you have received this email in error, please
 contact the sender by replying and delete this email so that it is not
 recoverable. If you are not the intended recipient(s), any retention, review,
 disclosure, distribution, copying, printing, dissemination, or other use of,
 or taking of any action in reliance upon, this information is strictly
 prohibited and without liability on our part.

Date: Thu, 17 Jan 2002 16:43:20 +0100
From: Patrick <[email-masked]>
To: [email-masked]
Subject: Re: <info> Command and authInfo
Organization: Gandi
Sender: [email-masked]

On Tue, Jan 15, 2002 at 10:28:50AM -0500, Hollenbeck, Scott took time to write:
> I'm not so sure of the benefit in putting <authInfo> into the <update>,
> <delete> and <renew> commands given the discussion we had on the list some
> time ago (we DID have it that way, and then folks wanted it removed from all
> but <transfer>), but I understand what you're saying about the dates and the
> <info> command. 

I agree with Bruce on this : the authinfo should have a bigger scope.

Right now it is only for transfers (and thus should have been called
transfer auth or something like that, not auth info), and as we
already see it with some Registries using EPP, transfers are hard.

The auth info does not help anything regarding transfers.
It just complicates things (current Registrar not giving it, and if
the new Registrar already asks contacts for approval, the authinfo is
of nouse... since it will be given to contacts, thus same problems in
both case of hijacking and such).

IMNSHO auth info should enable someone having it to make
modifications (that is update at least, maybe delete and renew)
through any other ways (other Registrars, or even the Registry
directly). Protocols should make that possible, and then 
local policies should specify if it is to be used or not, and if yes,
how.

Regards,
Patrick.

From: "Liu, Hong" <[email-masked]>
To: "'Hollenbeck, Scott'" <[email-masked]>, "'Bruce Tonkin'" <[email-masked]>
Cc: [email-masked]
Subject: RE: MX records in epp
Date: Thu, 17 Jan 2002 08:53:01 -0600
Sender: [email-masked]

Scott, Bruce,

Please also include me in this discussion. Thanks!

--Hong

To: "Hollenbeck, Scott" <[email-masked]>
cc: "'Bruce Tonkin'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: MX records in epp 
Date: Thu, 17 Jan 2002 08:02:09 -0800
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott, Bruce,

Please copy me on this (<domain:mx>).

TiA,
Eric
wampumpeag, llc

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Bruce Tonkin'" <[email-masked]>
Cc: [email-masked]
Subject: RE: MX records in epp
Date: Thu, 17 Jan 2002 07:16:45 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Bruce Tonkin [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2002 9:02 PM
> To: 'Hollenbeck, Scott'
> Cc: [email-masked]
> Subject: MX records in epp
> 
> 
> Hello Scott,
> 
> In the ".com.au" zone file we have MX records for some 
> domains instead of NS
> records.
> 
> e.g domainname.com.au   IN    MX 10    mailserver.com.au
> 
> How do you think this should be accommodated within EPP.?
> 
> The domain name mapping object currently has:
> <domain:ns>
> <domain:host>
> 
> Do we need a:
> <domain:mx>?

As Dave Crocker noted, the general provisioning case for MX records is
within leaf-node zones.  If there are exceptions, like in .com.au, I'd
suggest defining a protocol extension to the domain mapping to describe MX
record provisioning.  Let's take it off-list if you'd like to explore that
option.

-Scott-

Date: Wed, 16 Jan 2002 18:26:20 -0800
To: Bruce Tonkin <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: MX records in epp
Cc: "'Hollenbeck, Scott'" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 01:01 PM 1/17/2002 +1100, Bruce Tonkin wrote:
>How do you think this should be accommodated within EPP.?

hmmm.  this is a case of administering entries within the domain name's 
leaf node, rather than administering the registry's entry pointing to that 
leaf node.

It is, of course, an entirely reasonable service to offer, but it also can 
easily be viewed as a separate activity from basic domain name "registration".

Given that there are a variety of additional uses and venues being 
contemplated for the protocol, perhaps this query raises an easy second 
venue to explore... once the current one is completed.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

From: Bruce Tonkin <[email-masked]>
To: "'Hollenbeck, Scott'" <[email-masked]>
Cc: [email-masked]
Subject: MX records in epp
Date: Thu, 17 Jan 2002 13:01:37 +1100
Sender: [email-masked]

Hello Scott,

In the ".com.au" zone file we have MX records for some domains instead of NS
records.

e.g domainname.com.au   IN    MX 10    mailserver.com.au

How do you think this should be accommodated within EPP.?

The domain name mapping object currently has:
<domain:ns>
<domain:host>

Do we need a:
<domain:mx>?

For further info. see RFC974: MAIL ROUTING AND THE DOMAIN SYSTEM

and section 8 of RFC1035.

Bruce Tonkin

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-grrp-reqs-05.txt
Date: Wed, 16 Jan 2002 07:03:35 -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		: Generic Registry-Registrar Protocol Requirements
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-grrp-reqs-05.txt
	Pages		: 24
	Date		: 15-Jan-02
	
This document describes high-level functional and interface
requirements for a client-server protocol for the registration and
management of Internet domain names in shared registries. Specific
technical requirements detailed for protocol design are not presented
here.  Instead, this document focuses on the basic functions and
interfaces required of a protocol to support multiple registry and
registrar operational models.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-05.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-grrp-reqs-05.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-grrp-reqs-05.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-grrp-reqs-05.txt

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

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

--OtherAccess--

--NextPart--

Date: Wed, 16 Jan 2002 12:47:55 +0100
From: Jens-Uwe Gaspar <[email-masked]>
Organization: Schlund + Partner AG
To: "Hollenbeck, Scott" <[email-masked]>
CC: [email-masked]
Subject: Re: <info> Command and authInfo
Sender: [email-masked]

"Hollenbeck, Scott" wrote:
> 
> > -----Original Message-----
> > From: Jens-Uwe Gaspar [mailto:[email-masked]]
> > Sent: Tuesday, January 15, 2002 1:06 PM
> > To: [email-masked]
> > Subject: Re: <info> Command and authInfo
> >
> > While registering a new object (domain, contact or host), it
> > may happen,
> > that in the registry the object was registered, but
> > accidently our database
> > will fail (cause of deadlock, DB-maintenance, or whatever).
> > Because there's no transaction enclosing registry _and_
> > registrars actions,
> > we must recommence registering the object (dom/contact/host):
> >
> >   <check> existence of object;
> >   if existing, do <info> to get [sponsoring registrar]:
> >     if [sponsoring registrar] not equal to ourselves => we're
> > sad registrar
> >        and stop further action for this object
> >     else: we're happy registrar and go on with further actions :)
> >
> > In practice it stands the test (.INFO/.BIZ) and we would appreciate,
> > if that's also be possible in future versions of EPP.
> 
> You can achieve exactly the same results without having to determine the
> sponsoring client.  Do an <info>, if you're not the sponsor you get back a
> "you're not authorized" error code => you're sad.  If you are, <info> works
> and you're happy.  It's also less work for the server if you're not the
> sponsor as no data has to be retrieved from a local data store to generate
> the error response.

I'm aware of that, but when i follow Bruce Tonkin's note:

  BT> Bear in mind, that in future the use of EPP to talk to the
  BT> registry may not be restricted to entities such as authorised
  BT> registrars [...]

then there maybe

  a) normal users doing an <info> -> "not authorized", maybe because
     client has no access-right to do it, or
  b) registrar doing an <info> -> "not authorized", because not
     current sponsoring registrar,
  c) registrar doing an <info> -> "not authorized", because not allowed
     to do it (of whatever reason there could be: e.g. billing, etc).

I'm not sure, if it's a good idea to use the error code "not authorized"
to indicate that you're not the sponsoring registrar (b), because
then you can't differ it from case (c) stated above.

>
> With respect to current implementations, while I can appreciate the insights
> gained in writing code to the specs, we as WG can't have our focus limited
> by code written to I-Ds.  We need to be able to change the specs as issues
> are found and explored, even if that means someone might have to change
> code.

Sure, i only wanted to give an example in which the <info>-data is used.

> 
> > Do you want to restrict returning the object data completely, or do you
> > allow returning parts (changing minOccurs in the specs)?
> >
> > For example, reducing <info> result-data to the output the corresponding
> > whois-server list, if requested by a registrar other than the current
> > sponsoring one.
> 
> This might be a reasonable compromise.  My initial thought was to restrict
> it completely, but maybe there's no harm in returning a subset of the info
> if the querying client isn't the sponsor and doesn't have the authInfo.
> 
> -Scott-

Best regards,

Jens-Uwe Gaspar

________________________________________________________________________
Jens-Uwe Gaspar                              Schlund + Partner AG
E-Mail: [email-masked]                       Erbprinzenstr. 4 - 12
Tel. +49-721-91374-50                        76133 Karlsruhe, Germany
Fax  +49-721-91374-20                        http://www.schlund.de

From: Bruce Tonkin <[email-masked]>
To: "'Hollenbeck, Scott'" <[email-masked]>, [email-masked]
Subject: RE: <info> Command and authInfo
Date: Wed, 16 Jan 2002 18:36:57 +1100
Sender: [email-masked]

Hello Scott,

> 
> This might be a reasonable compromise.  My initial thought 
> was to restrict
> it completely, but maybe there's no harm in returning a 
> subset of the info
> if the querying client isn't the sponsor and doesn't have the 
> authInfo.
> 

I prefer the latter option.  ie returning different subsets of information
depending on the credentials of the party executing the <info> command.

Bear in mind, that in future the use of EPP to talk to the registry may not
be restricted to entities such as authorised registrars (that is really only
an artifact of the current ".biz", ".info" etc structure).  There is no
reason why any member of public should not be able to query the registry via
EPP (and get the advantage of structured XML responses) and get back public
info (such as WHOIS info).  Of course you could even create a separate WHOIS
like service using separate infrastructure that responds to EPP <info>
commands.  In some ways it may relieve some of the debate in WHOIS - where
debate runs wild on appropriate data formats etc.

Regards,
Bruce Tonkin

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Jens-Uwe Gaspar'" <[email-masked]>, [email-masked]
Subject: RE: <info> Command and authInfo
Date: Tue, 15 Jan 2002 20:52:33 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Jens-Uwe Gaspar [mailto:[email-masked]]
> Sent: Tuesday, January 15, 2002 1:06 PM
> To: [email-masked]
> Subject: Re: <info> Command and authInfo
> 
> 
> 
> While registering a new object (domain, contact or host), it 
> may happen,
> that in the registry the object was registered, but 
> accidently our database
> will fail (cause of deadlock, DB-maintenance, or whatever).
> Because there's no transaction enclosing registry _and_ 
> registrars actions,
> we must recommence registering the object (dom/contact/host):
> 
>   <check> existence of object;
>   if existing, do <info> to get [sponsoring registrar]:
>     if [sponsoring registrar] not equal to ourselves => we're 
> sad registrar
>        and stop further action for this object
>     else: we're happy registrar and go on with further actions :)
> 
> In practice it stands the test (.INFO/.BIZ) and we would appreciate,
> if that's also be possible in future versions of EPP.

You can achieve exactly the same results without having to determine the
sponsoring client.  Do an <info>, if you're not the sponsor you get back a
"you're not authorized" error code => you're sad.  If you are, <info> works
and you're happy.  It's also less work for the server if you're not the
sponsor as no data has to be retrieved from a local data store to generate
the error response.

With respect to current implementations, while I can appreciate the insights
gained in writing code to the specs, we as WG can't have our focus limited
by code written to I-Ds.  We need to be able to change the specs as issues
are found and explored, even if that means someone might have to change
code.

> Do you want to restrict returning the object data completely, or do you
> allow returning parts (changing minOccurs in the specs)?
> 
> For example, reducing <info> result-data to the output the corresponding
> whois-server list, if requested by a registrar other than the current
> sponsoring one.

This might be a reasonable compromise.  My initial thought was to restrict
it completely, but maybe there's no harm in returning a subset of the info
if the querying client isn't the sponsor and doesn't have the authInfo.

-Scott-

From: Bruce Tonkin <[email-masked]>
To: "'Hollenbeck, Scott'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: <info> Command and authInfo
Date: Wed, 16 Jan 2002 12:42:34 +1100
Sender: [email-masked]

Hello Scott,

> 
> I'm not so sure of the benefit in putting <authInfo> into the 
> <update>,
> <delete> and <renew> commands given the discussion we had on 
> the list some
> time ago (we DID have it that way, and then folks wanted it 
> removed from all
> but <transfer>), but I understand what you're saying about 
> the dates and the
> <info> command.  

I can't remember the previous discussions, but I am only saying that it
should be available OPTIONALLY.

There are some better securiy models possible, where passwords may be
dynamically updated, that might result in transaction security for updates
etc being done on a per domain name level, rather than relying solely on
registrar security/authentication (via the login command).

A potential security flaw in the current system, is that if the registrar is
compromised, than an un-authorised entity could potentially have access to
update etc - all records associated with that particular registrar.

I think from a generic registry perspective, it should be possible to
provide better security around commands that change the status of individual
objects in the registry.

I can think of value added services, where additional security could be
purchased from the registry via registrars for some domain names.

Regards,
Bruce Tonkin

Date: Tue, 15 Jan 2002 19:05:58 +0100
From: Jens-Uwe Gaspar <[email-masked]>
Organization: Schlund + Partner AG
To: [email-masked]
Subject: Re: <info> Command and authInfo
Sender: [email-masked]

Rick H Wesson wrote:
>...
> On Mon, 14 Jan 2002, Hollenbeck, Scott wrote:
>...
> > You've suggested that "the status command should be open to all registrars".
> > Let's change "status" to <info> to make this about EPP and not RRP.  Here's
> > my question to you: other than as part of requesting a transfer, what other
> > _technical_ reason(s) does a client have to perform an <info> command on a
> > domain sponsored by another client?
> 
> durring expiration, if its a name you are competeing over its a
> requirement to know if the domain is recently registered. there are other
> examples but I can't disclose some other registrar's business practices

While registering a new object (domain, contact or host), it may happen,
that in the registry the object was registered, but accidently our database
will fail (cause of deadlock, DB-maintenance, or whatever).
Because there's no transaction enclosing registry _and_ registrars actions,
we must recommence registering the object (dom/contact/host):

  <check> existence of object;
  if existing, do <info> to get [sponsoring registrar]:
    if [sponsoring registrar] not equal to ourselves => we're sad registrar
       and stop further action for this object
    else: we're happy registrar and go on with further actions :)

In practice it stands the test (.INFO/.BIZ) and we would appreciate,
if that's also be possible in future versions of EPP.

Do you want to restrict returning the object data completely, or do you
allow returning parts (changing minOccurs in the specs)?

  For example, reducing <info> result-data to the output the corresponding
  whois-server list, if requested by a registrar other than the current
  sponsoring one.

Best regards,

Jens-Uwe Gaspar

> [snip]

________________________________________________________________________
Jens-Uwe Gaspar                              Schlund + Partner AG
E-Mail: [email-masked]                       Erbprinzenstr. 4 - 12
Tel. +49-721-91374-50                        76133 Karlsruhe, Germany
Fax  +49-721-91374-20                        http://www.schlund.de

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Bruce Tonkin'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: <info> Command and authInfo
Date: Tue, 15 Jan 2002 10:28:50 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Bruce Tonkin [mailto:[email-masked]]
> Sent: Monday, January 14, 2002 6:42 PM
> To: 'Hollenbeck, Scott'
> Cc: [email-masked]'
> Subject: RE: <info> Command and authInfo
> 
> 
> Hello Scott,
> 
> > 
> > I'm wondering how people feel about adding an optional <authInfo>
element to
> > the domain <info> command.

[snip]

> I would support that.  I have been reviewing the EPP specs for ".au", and
I
> had the same thought that the authinfo element should be available with
> commands other than transfer, but that it should be optional.  You might
> consider it for <update>, <delete> and <renew>.
> 
> It provides a bit more flexibility for the registry.
> 
> I also think that some of the <info> data elements in the
epp-domain-03.txt
> should be made optional (ie minOccurs="0") (ie returned to the sponsoring
> registrar only, or returned to a registrar that uses the authinfo
element).
> For example: <domain:crDate> and <domain:exDate>.  These two dates are
being
> used extensively in Australia for unsolicited spamming of registrants for
> renewals.  We don't currently display expiry date information to other
than
> the sponsoring reseller.

Bruce,

I'm not so sure of the benefit in putting <authInfo> into the <update>,
<delete> and <renew> commands given the discussion we had on the list some
time ago (we DID have it that way, and then folks wanted it removed from all
but <transfer>), but I understand what you're saying about the dates and the
<info> command.  While there might be business models built around acquiring
those dates, I'm not sure that it's good engineering to have _all_ domain
info available to any client who cares to look.

-Scott-

From: Bruce Tonkin <[email-masked]>
To: "'Hollenbeck, Scott'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: <info> Command and authInfo
Date: Tue, 15 Jan 2002 10:41:30 +1100
Sender: [email-masked]

Hello Scott,

> 
> I'm wondering how people feel about adding an optional 
> <authInfo> element to
> the domain <info> command.  Sponsoring clients wouldn't have 
> to use it; they
> can continue to "see" all of the domains they sponsor.  
> Clients who need to
> see something in the context of a transfer can provide the 
> <authInfo> to see
> domain object info via the protocol, eliminating the need to 
> go out-of-band.
> Data mining protections are still in place because 
> non-sponsoring clients
> who don't have the <authInfo> can't see domains sponsored by 
> other clients.
> 
> This sort of change would let us tighten up the EPP spec a 
> bit, which should
> help with interoperability.  I know we finished a WG last 
> call, but I'm in
> the docs now working on wrapping up the changes based on 
> last-call comments
> and would like to know how folks feel about this change given their
> operational experience with RRP.
> 

I would support that.  I have been reviewing the EPP specs for ".au", and I
had the same thought that the authinfo element should be available with
commands other than transfer, but that it should be optional.  You might
consider it for <update>, <delete> and <renew>.

It provides a bit more flexibility for the registry.

I also think that some of the <info> data elements in the epp-domain-03.txt
should be made optional (ie minOccurs="0") (ie returned to the sponsoring
registrar only, or returned to a registrar that uses the authinfo element).
For example: <domain:crDate> and <domain:exDate>.  These two dates are being
used extensively in Australia for unsolicited spamming of registrants for
renewals.  We don't currently display expiry date information to other than
the sponsoring reseller.

Regards,
Bruce Tonkin

Date: Mon, 14 Jan 2002 11:38:52 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: <info> Command and authInfo
Sender: [email-masked]

Scott,

On Mon, 14 Jan 2002, Hollenbeck, Scott wrote:

>
> "This action SHOULD be limited to authorized clients; restricting this
> action to the sponsoring client is RECOMMENDED."
>
> My contention is that this leaves room for interoperability problems.  A
> client who expects a server to support unrestricted <info> commands will
> likely have problems at a higher layer when working with another server that
> restricts <info> commands as described in the spec.  Maybe this is a false
> assumption on my part, but that's why I floated the idea in the first place.

yes it does, but thick and thin registries may not interoperate? there are
other areas that registry policy MAY interfere with interoperability too
such as how name servers are handeled.

> I recognize the problem with RRP in the context of domain transfers, and I
> don't want EPP to have the same problem.  The gaining client has a
> legitimate reason to see domain info as part of processing a transfer
> request, they have the <authInfo> in-hand, and if the <info> command is
> changed as I described the client can perform the <info> command
> successfully.  As the specs are currently written, a server can legitimately
> prevent the gaining client from performing the <info> command.  I wanted to
> suggest a change to make this scenario work while sticking to the spirit of
> the "authorized clients" recommendation.

then may i suggest the following language.

 "This action SHOULD be limited to authorized clients; restricting this
  action to the sponsoring client is NOT RECOMMENDED."

it has the same effect on interoperability.

> You've suggested that "the status command should be open to all registrars".
> Let's change "status" to <info> to make this about EPP and not RRP.  Here's
> my question to you: other than as part of requesting a transfer, what other
> _technical_ reason(s) does a client have to perform an <info> command on a
> domain sponsored by another client?

durring expiration, if its a name you are competeing over its a
requirement to know if the domain is recently registered. there are other
examples but I can't disclose some other registrar's business practices

> Sorry if you've answered that question in some other forum recently, but
> what I recall was gleaned from our shared experiences of mid-1999.  Knowing
> that some registries will likely implement EPP to the "authorized clients"
> recommendation, I wanted to propose a solution that takes care of the
> problem in the context of transfers.  Yes, opening up the command completely
> would also eliminate the problem, but I feel very strongly that it
> introduces other problems relating to privacy and load management.  Yes,
> some of the info returned in response to an <info> command is publicly
> available via whois, but not everything is.

the issues I have here is that your suggested fix to this "problem" is
that it re-enforces a position, piticular to your employer, and the
VeriSign Registrar. this where our misunderstanding might stem from, your
suggestion makes it much easier for VGRS to implement a policy in EPP that
Registrars using RRP have found VERY cumbersome.

it is hard to keep RRP out of the converstaion as it has provided us
with a wealth of reasons why the <info> command should be available to all
registrars.

personal regards,

-rick

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Rick H Wesson'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: <info> Command and authInfo
Date: Mon, 14 Jan 2002 14:20:27 -0500
Sender: [email-masked]

Rick,

While I appreciate the apology, I still think you're misunderstanding the
intent of the proposal.  The EPP spec has had recommendations in it (see the
last paragraph of section 2.8.2.2 of epp-05, for example) for quite some
time to describe how the commands should be implemented:

"This action SHOULD be limited to authorized clients; restricting this
action to the sponsoring client is RECOMMENDED."

My contention is that this leaves room for interoperability problems.  A
client who expects a server to support unrestricted <info> commands will
likely have problems at a higher layer when working with another server that
restricts <info> commands as described in the spec.  Maybe this is a false
assumption on my part, but that's why I floated the idea in the first place.

I recognize the problem with RRP in the context of domain transfers, and I
don't want EPP to have the same problem.  The gaining client has a
legitimate reason to see domain info as part of processing a transfer
request, they have the <authInfo> in-hand, and if the <info> command is
changed as I described the client can perform the <info> command
successfully.  As the specs are currently written, a server can legitimately
prevent the gaining client from performing the <info> command.  I wanted to
suggest a change to make this scenario work while sticking to the spirit of
the "authorized clients" recommendation.

You've suggested that "the status command should be open to all registrars".
Let's change "status" to <info> to make this about EPP and not RRP.  Here's
my question to you: other than as part of requesting a transfer, what other
_technical_ reason(s) does a client have to perform an <info> command on a
domain sponsored by another client?

Sorry if you've answered that question in some other forum recently, but
what I recall was gleaned from our shared experiences of mid-1999.  Knowing
that some registries will likely implement EPP to the "authorized clients"
recommendation, I wanted to propose a solution that takes care of the
problem in the context of transfers.  Yes, opening up the command completely
would also eliminate the problem, but I feel very strongly that it
introduces other problems relating to privacy and load management.  Yes,
some of the info returned in response to an <info> command is publicly
available via whois, but not everything is.

Finally, there was a recent thread on the list [1] about requiring
<authInfo> for transfer queries.  Folks supported that change.  Don't the
same privacy concerns come into play here?

-Scott-

[1]
http://www.cafax.se/ietf-provreg/maillist/2001-11/msg00043.html

> -----Original Message-----
> From: Rick H Wesson [mailto:[email-masked]]
> Sent: Monday, January 14, 2002 1:01 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]'
> Subject: RE: <info> Command and authInfo
> 
> 
> 
> Scott,
> 
> ok, my comments were not meant as an ad-hominem attack on you, we have
> known each other a long time and I'm not attacking you 
> personally, but I
> do have strong opinion on the subject from a long experience with RRP.
> 
> registries have a contract with registrars and MUST enforce those
> contracts; we should not be designing defense from datamining into the
> protocols. registries MUST enforce their contracts and 
> provide appropriate
> oversite of the registrars.
> 
> We have recent experience of registrars abusing the common 
> resource of a
> RRP based registry, just because the Registry does not enforce their
> contracts does not mean we should design mechanisms into the 
> protocol to
> cover administrative procedures.
> 
> I hope this clarifies my previous comment. apologies if you 
> thought they
> were of a personal nature directed at you.
> 
> personal regards,
> 
> -rick

Date: Mon, 14 Jan 2002 10:01:14 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: <info> Command and authInfo
Sender: [email-masked]

Scott,

ok, my comments were not meant as an ad-hominem attack on you, we have
known each other a long time and I'm not attacking you personally, but I
do have strong opinion on the subject from a long experience with RRP.

registries have a contract with registrars and MUST enforce those
contracts; we should not be designing defense from datamining into the
protocols. registries MUST enforce their contracts and provide appropriate
oversite of the registrars.

We have recent experience of registrars abusing the common resource of a
RRP based registry, just because the Registry does not enforce their
contracts does not mean we should design mechanisms into the protocol to
cover administrative procedures.

I hope this clarifies my previous comment. apologies if you thought they
were of a personal nature directed at you.

personal regards,

-rick

On Mon, 14 Jan 2002, Hollenbeck, Scott wrote:

> > -----Original Message-----
> > From: Rick H Wesson [mailto:[email-masked]]
> > Sent: Monday, January 14, 2002 12:24 PM
> > To: Hollenbeck, Scott
> > Cc: [email-masked]'
> > Subject: Re: <info> Command and authInfo
> >
> >
> >
> > please don't turn this spec into VeriSigns view of a Domain Registry. Up
> > till now you have done a good job of engineering but it seems as though
> > your employer is creeping into your work.
>
> Rick, I really object to any insinuation that there's any employer bias
> creeping into anything here.  My comments on RRP were provided to document
> experience with a similar protocol.  Data mining is a real issue, and the
> current EPP spec has said for a LONG time about the way the info command
> should be implemented -- and it's NOT what you suggested ("the status
> command should be open to all registrars").  Instead of an ad-hominem
> attack, why not address the data mining risk and merit or detriment of the
> change proposal?
>
> -Scott-
>

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Rick H Wesson'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: <info> Command and authInfo
Date: Mon, 14 Jan 2002 12:37:31 -0500
Sender: [email-masked]

> -----Original Message-----
> From: Rick H Wesson [mailto:[email-masked]]
> Sent: Monday, January 14, 2002 12:24 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]'
> Subject: Re: <info> Command and authInfo
> 
> 
> 
> please don't turn this spec into VeriSigns view of a Domain Registry. Up
> till now you have done a good job of engineering but it seems as though
> your employer is creeping into your work.

Rick, I really object to any insinuation that there's any employer bias
creeping into anything here.  My comments on RRP were provided to document
experience with a similar protocol.  Data mining is a real issue, and the
current EPP spec has said for a LONG time about the way the info command
should be implemented -- and it's NOT what you suggested ("the status
command should be open to all registrars").  Instead of an ad-hominem
attack, why not address the data mining risk and merit or detriment of the
change proposal?

-Scott-

Date: Mon, 14 Jan 2002 09:24:24 -0800 (PST)
From: Rick H Wesson <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: <info> Command and authInfo
Sender: [email-masked]

Scott,

On Mon, 14 Jan 2002, Hollenbeck, Scott wrote:

> Those of you familiar with the NSI RRP, the protocol's STATUS command, and
> the way it's been implemented in the com|net|org registry are probably aware
> that RRP clients can only do a STATUS command on domains that they've
> registered.  A client who attempts to get status on a domain registered by a
> different client gets an error response.
>
> The EPP specification is a bit more flexible in this regard, saying this
> about the essentially similar <info> command:
>
> "This action SHOULD be limited to authorized clients; restricting this
> action to the sponsoring client is RECOMMENDED."
>
> VeriSign often gets registrar requests to open up the RRP STATUS command
> completely so that any client can obtain information about any registered
> domain.  The usual argument to support this request relates to transfers:
> the potential gaining client wants to be able to see what they're getting in
> to before requesting the transfer.  Opening the command up completely
> introduces a data mining risk, so that's why the EPP text is written as it
> is, but without allowing some cross-vision the gaining client has to go to
> an out-of-band mechanism (like whois) to obtain info.  I think we can do
> better with EPP without opening a significant data mining risk.

thanks to competition we now understand how usefull it is to preform a
INFO command on a domain.

> I'm wondering how people feel about adding an optional <authInfo> element to
> the domain <info> command.  Sponsoring clients wouldn't have to use it; they
> can continue to "see" all of the domains they sponsor.  Clients who need to
> see something in the context of a transfer can provide the <authInfo> to see
> domain object info via the protocol, eliminating the need to go out-of-band.
> Data mining protections are still in place because non-sponsoring clients
> who don't have the <authInfo> can't see domains sponsored by other clients.

no.

please don't turn this spec into VeriSigns view of a Domain Registry. Up
till now you have done a good job of engineering but it seems as though
your employer is creeping into your work.

Registrars believe that the status command should be open to all
registrars even those that use RRP and shoreing up your employers position
by altering the <info> command so that your employer can continue to
maintain their position is not the kninds of changes I think we need in
EPP.

> This sort of change would let us tighten up the EPP spec a bit, which should
> help with interoperability.  I know we finished a WG last call, but I'm in
> the docs now working on wrapping up the changes based on last-call comments
> and would like to know how folks feel about this change given their
> operational experience with RRP.

IMHO, we should not support this change, and that VGRS should open up
their status command and VGRS should allow the EPP <info> command on
domains. This is what Registrars have been asking for since the registry
opened, isn't anyone listening?

-rick

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: <info> Command and authInfo
Date: Mon, 14 Jan 2002 11:33:56 -0500
Sender: [email-masked]

Those of you familiar with the NSI RRP, the protocol's STATUS command, and
the way it's been implemented in the com|net|org registry are probably aware
that RRP clients can only do a STATUS command on domains that they've
registered.  A client who attempts to get status on a domain registered by a
different client gets an error response.

The EPP specification is a bit more flexible in this regard, saying this
about the essentially similar <info> command:

"This action SHOULD be limited to authorized clients; restricting this
action to the sponsoring client is RECOMMENDED."

VeriSign often gets registrar requests to open up the RRP STATUS command
completely so that any client can obtain information about any registered
domain.  The usual argument to support this request relates to transfers:
the potential gaining client wants to be able to see what they're getting in
to before requesting the transfer.  Opening the command up completely
introduces a data mining risk, so that's why the EPP text is written as it
is, but without allowing some cross-vision the gaining client has to go to
an out-of-band mechanism (like whois) to obtain info.  I think we can do
better with EPP without opening a significant data mining risk.

I'm wondering how people feel about adding an optional <authInfo> element to
the domain <info> command.  Sponsoring clients wouldn't have to use it; they
can continue to "see" all of the domains they sponsor.  Clients who need to
see something in the context of a transfer can provide the <authInfo> to see
domain object info via the protocol, eliminating the need to go out-of-band.
Data mining protections are still in place because non-sponsoring clients
who don't have the <authInfo> can't see domains sponsored by other clients.

This sort of change would let us tighten up the EPP spec a bit, which should
help with interoperability.  I know we finished a WG last call, but I'm in
the docs now working on wrapping up the changes based on last-call comments
and would like to know how folks feel about this change given their
operational experience with RRP.

-Scott- 

Date: Fri, 11 Jan 2002 07:16:22 -0500 (EST)
From: Scott  Bradner <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Requirements Document Update
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

>I have cc:ed the transport area directors which can correct me if/where I
> have been wrong in the explanation above.

the explanation is fine

> IF you want to also run this protocol on for example UDP, your protocol
> would end up being much more complicated.

trying to build your own (instead of using TCP or SCTP) could easily
add a year or more to the development effort - congestion control
protocols are quite hard to get right

Scott

To: Scott Bradner <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Requirements Document Update 
Date: Thu, 10 Jan 2002 22:59:19 -0800
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Scott and Allison,

Thanks. The UDP problem statement ("avoid") is fine. I was concerned over
the only-tcp-or-sctp construction of orthodoxy, since I don't see any
reason not to provide a transport mapping for smtp/uucp. I just haven't
gotten around to writing it (a-must-do-by-ICANN-Accra).

Eric

Date: Fri, 11 Jan 2002 09:47:34 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Re: Requirements Document Update
Cc: Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=  <[email-masked]>, Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, Allison Mankin <[email-masked]>, Scott Bradner <[email-masked]>, Ned Freed <[email-masked]>
Sender: [email-masked]

Thanks to all for the clarifications.  Scott submitted a new draft based on
the comments received earlier.  If we think the clarifications mean a more
general edit is needed, we'll have another soon.

At 8:14 AM -0500 1/11/02, Allison Mankin wrote:
>Patrik,
>
>I would only add to what you and Scott wrote that:
>
>> _somewhere_ in the protocol stack there has to be congestion control
>
>It is not only a large undertaking to put congestion control in
>the application itself, but it may greatly distort the application
>protocol if it has the requirement to make the network timing
>measurements needed for congestion control (taken care of by
>using TCP or SCTP).
>
>We asked for the wording in the provreg document to encourage
>provreg not to choose UDP as the transport and then be forced
>to provide application congestion control as well.
>
>Allison
>
>
>
>Allison

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

Date: Fri, 11 Jan 2002 07:16:22 -0500 (EST)
From: Scott  Bradner <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Requirements Document Update
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

>I have cc:ed the transport area directors which can correct me if/where I
> have been wrong in the explanation above.

the explanation is fine

> IF you want to also run this protocol on for example UDP, your protocol
> would end up being much more complicated.

trying to build your own (instead of using TCP or SCTP) could easily
add a year or more to the development effort - congestion control
protocols are quite hard to get right

Scott

To: Patrik =?ISO-8859-1?Q?F=E4ltstr=F6m?= <[email-masked]>
cc: Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>, Allison Mankin <[email-masked]>, Scott Bradner <[email-masked]>, Ned Freed <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Requirements Document Update 
Date: Fri, 11 Jan 2002 08:14:05 -0500
From: Allison Mankin <[email-masked]>
Sender: [email-masked]

Patrik,

I would only add to what you and Scott wrote that:

> _somewhere_ in the protocol stack there has to be congestion control

It is not only a large undertaking to put congestion control in
the application itself, but it may greatly distort the application
protocol if it has the requirement to make the network timing
measurements needed for congestion control (taken care of by
using TCP or SCTP).

We asked for the wording in the provreg document to encourage
provreg not to choose UDP as the transport and then be forced
to provide application congestion control as well. 

Allison

Allison

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-provreg-grrp-reqs-04.txt
Date: Fri, 11 Jan 2002 08:56:49 -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		: Generic Registry-Registrar Protocol Requirements
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-grrp-reqs-04.txt
	Pages		: 24
	Date		: 10-Jan-02
	
This document describes high-level functional and interface
requirements for a client-server protocol for the registration and
management of Internet domain names in shared registries. Specific
technical requirements detailed for protocol design are not presented
here.  Instead, this document focuses on the basic functions and
interfaces required of a protocol to support multiple registry and
registrar operational models.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-provreg-grrp-reqs-04.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-grrp-reqs-04.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-grrp-reqs-04.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-grrp-reqs-04.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 10 Jan 2002 22:19:25 -0800
To: Bill Manning <[email-masked]>
From: Dave Crocker <[email-masked]>
Subject: Re: Requirements Document Update
Cc: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>
Sender: [email-masked]

At 08:50 AM 1/4/2002 -0800, Bill Manning wrote:
> > "The protocol MUST only be run over IETF approved protocols that feature
> > congestion control, such as TCP and SCTP."
>
>         So, the protcol is prohibited from running on non-IESG approved
>         protocols?  How the heck are they going to enforce that?

Although the wording is a bit awkward, the requirement is pretty 
straightforward.

Enforcement is by giving or withholding the IETF standards imprimateur.

Obviously requirements cannot be enforced behaviorally.  You may run any 
darn thing you choose to run.

However violating the above requirements means that what you run will not 
be an IETF standard.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

Date: Thu, 10 Jan 2002 22:02:05 -0800
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
To: Edward Lewis <[email-masked]>, "[email-masked]'" <[email-masked]>
cc: Allison Mankin <[email-masked]>, Scott Bradner <[email-masked]>, Ned Freed <[email-masked]>
Subject: RE: Requirements Document Update
Sender: [email-masked]

--On 2002-01-07 10.02 -0500 Edward Lewis <[email-masked]> wrote:

> At 11:48 AM -0500 1/4/02, Hollenbeck, Scott wrote:
>> More to the point, I think the intention is to ensure that IETF-specified
>> protocol documents don't build on "problematic" transports.  Maybe Ed can
>> provide more detail based on the exchange he had with Patrik.
> 
> Sorry, I can't.  When I asked about the motivation of the new text, I was
> told it was to ensure (okay, require) that congestion control was part of
> the transport.  My guess is that this is some concern that blew through
> the IESG in response to some other networking technology, perhaps
> telephony related.  But I am just guessing.

The view in the IESG on new protocols is that _somewhere_ in the protocol
stack there has to be congestion control. Either one have to include
congestion control in the protocol itself, or one rely on underlying
technologies for it.

What IESG suggested was to have a requirement that the protocol you are
developing must run on a transport that itself have congestion control
(like TCP or SCTP), and that way, you don't have to include such things in
your protocol.

IF you want to also run this protocol on for example UDP, your protocol
would end up being much more complicated.

I have cc:ed the transport area directors which can correct me if/where I
have been wrong in the explanation above.

Now, Scott seems to have created a new version, even though I still only
see version -03 in the archive.

Scott, Ed, can you let me know if you see the new version before me?

   paf

To: Edward Lewis <[email-masked]>
cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Minutes from SLC 
Date: Thu, 10 Jan 2002 05:46:03 -0800
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

> The WG is open to discussion of <push>.

Good.

To: Dave Crocker <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Minutes from SLC 
Date: Thu, 10 Jan 2002 05:27:38 -0800
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Dave,

The sense of the meeting (London) was that <push>, when removed from the
XRP draft (like transport over BEEP), would be a WG draft. When Ed took
the question to the WG (the list), there was no consensus to accept a WG
draft containing <push>.

I'm just fishing for the end of a wait statement, and I didn't see it in
the SLC minutes.

Eric

Date: Thu, 10 Jan 2002 10:38:43 -0800
To: [email-masked]
From: Dave Crocker <[email-masked]>
Subject: Re: Minutes from SLC
Sender: [email-masked]

>The WG is open to discussion of <push>.  I think that the ground work is
>already in place to have this enter as a WG document, given the discussion
>to date.

In fact, I thought that issue had been disposed of long ago, namely that we 
had consensus to have push be *official* as an *option*, standardized in a 
separate document.  (or in the appendix of the main document, but that is 
entirely a matter of convenience.)

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

Date: Thu, 10 Jan 2002 13:28:33 -0500
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: Re: Minutes from SLC
Cc: Edward Lewis <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

The WG is open to discussion of <push>.  I think that the ground work is
already in place to have this enter as a WG document, given the discussion
to date.

If there is an issue over "control,"  I think we should "burn that bridge
when we come to it" as an ex-officemate used to say.

At 5:18 AM -0500 1/10/02, Eric Brunner-Williams in Portland Maine wrote:
>Ed,
>
>I'm still waiting on the-sense-of-the-wg on the question that came up on
>the list post-London: what shall we do with <push>?
>
>The choices are:
>
>	- a draft under wg change control,
>	- a draft outside of the wg
>
>I'm fine with either approach.
>
>Eric

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

To: Edward Lewis <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Minutes from SLC 
Date: Thu, 10 Jan 2002 02:18:15 -0800
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

Ed,

I'm still waiting on the-sense-of-the-wg on the question that came up on
the list post-London: what shall we do with <push>?

The choices are:

	- a draft under wg change control,
	- a draft outside of the wg

I'm fine with either approach.

Eric

Date: Thu, 10 Jan 2002 12:53:44 -0500
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: Minutes from SLC
Sender: [email-masked]

Here are the minutes from the meeting last month.  I need to turn them in,
with Jim Gould's slides real soon, so let me know quickly if there are any
edits you want to see.

===========

Buchanan appointed as the scribe.

Ed Lewis:

Document status:

Definitions dropped.
Requirements in front of the IESG.
Last call:  EPP base; host, domain, and contact info mapping; and EPP over TCP.
Two other documents:  Containers and BEEP.  Will address later.
What will happen over the next couple of months?  Last call was just
concluded.

A few comments on last call items:
Scott Hollenbeck:

* Slight issue with the way XML schema deals with choices.  Right now could
say that you want to use the same things more than once.  Tradeoff between
getting multiple repeated elements or an empty ("none").
* Modification to domain mapping so that could delegate to name server
which is not a host object.
* Last issue:  want representation in more UTF-8-ful registration format.
Eric's suggestion-why do you need both?  We could just take whatever we
get.  Requirement in requirements draft.  Redundancy and extra elements;
get rid of

Jordyn Buchanan:
* The reason we added the non-registered objects as name servers was to
solve the out-of-zone hosts?

Hollenbeck: Yes

Buchanan:  I would prefer another solution to that problem if one is available.

Daniel Manley:  What does the new schema gain us if the first address is
still ASCII?

Hollenbeck: Gets rid of some elements, just have a variable number of
address elements.

Sheer El-Showk: Wasn't there a way to have per-registrar views of out-of
zone objects.  That seems like it might solve the problem.

Wesson:  Also, there's a difference between objects and records in the
document.

---

Lewis:  Will do presentations on implementations now.  First, Jim Gould.

Jim Gould: presentation (will be attached when sent to secretariate)

Rick:  Was registry thick or thin?

Gould:  We've done both.

<unknown>:  Did -04 release.  Toolkit supports Java/C++, been out since
summer.  Have been playing with extensions, but not released.  Have 100
registrars certified on EPP-04; looking at -05 and beyond.

Wesson: Registrars noticed issues with lengths.  Can you discuss:

<unknown>: As lengths changed, been very difficult to keep up.  From an
operational perspective, would be nice to get consistent.  Haven't had to
truncate because have been growing.

Hollenbeck:  Speaking of length, one last call issue was an increase of
postal address from 64 to 255 characters.

Lewis: Now Sheer El-Showk's presentation.

El-Showk:  We did both registry and registrar implementations.  I'm not
talking about the protocol itself.  A few small points.  Contact name field
is only a single field, versus two (first, last) in Whois.  Makes for a
difficult mapping.  Name/organization; name is a required field, whereas
organization is not.  Response codes should be more informative; not sure
extension mechanism would be appropriate.  New statuses may be required.
Business logic for statuses horrendous to implement; a significant part of
the business logic.  XML very expensive for check commands.  Lots of
overhead that is not necessary; because form data is identical, makes it
easier to do cryptanalysis.  Not clear how to implement an error condition
on a single check.

Manley:  Discussion of change in semantics of check command, adding
additional returned data.

El-Showk:  I don't like the idea of making it more complicated, should the
whole check fail if 1 out of 1000 returns an error.

Gould: I would assume that if one fails.

Buchanan:  Scenarios may exist in which one out of many could fail exist.

Gould: Then just fail the whole thing if your server logic can't figure out
what to do.

Wesson: There's no provision anywhere saying Whois has to say
firstname/lastname, so that's not a big deal.

El-Showk:  I also mentioned retry commands.  Relying on commands versus
transaction ID means that it may make it more difficult in the future.  Why
not client/server ID?

Hollenbeck:  Idempotency is a property.  By it's definition, it's the
structure of the command.  Take away or adding properties could hurt it.

El-Showk:  It's in mappings, not base protocol?

Hollenbeck: Yes.

El-Showk:  Wouldn't it be useful in the base protocol?  A unique client
trans ID could allow.

Hollenbeck:  We said the server wouldn't necessarily track; it's not a
requirement.

El-Showk:  In our implementation I did.

Lewis: Now Dan Manley.

Manley: A couple of comments; we used an early version of EPP, so many
comments are now out of date.  From a registrar perspective, transfers
aren't handled very well in batch.  May want to transfer hundreds or
thousands of names.  Easy to assimilate in RRP.  In EPP, it's more
difficult because each object could have different auth_info.  Couldn't
guarantee that the same domains had the same auth_info.  If there was a way
to group, that would be good.  Other issue is contacts, and contact
objects.  They are cool, but even more difficult to transfer; might have to
transfer many contacts.  Transfer a subset of the profile.  Containers
could solve; extend domain transfer command to take all contacts with it.

Hollenbeck:  Here's a scenario-I have a domain object with a specified
registrant, and a tech contact that belongs to an ISP.  Should the domain
transfer take the tech contact with it?

Manley:  True.  Hard to solve.

Wesson:  Might be appropriate to write a document on BCP from
registry/registrar perspective.  Would be really good.

Manley: I'll try to put my notes into a document.

Gould:  When you start selling other things than domains, they have to be
completely decoupled.  Might break other product associations.

Dan: This might move onto container discussions.

Buchanan: Could transfer contacts instantaneously and then act on them,
since the contact has the authorization built in and generally no billing
implications.

El-Showk: But then your domain and contacts could be out of sync.

Buchanan: I'm talking about situations when domain has already been
transferred and domain has been left behind.

Lewis: Should we be trying to send these documents up this month?

Wesson: I would encourage the group to move the documents forward.  Many of
the comments have been issues dealing with tracking the protocol as opposed
to actual implementation issues.

Lewis:  For implementations out there, over time we want to do some
interoperability testing.  That is the real test.

Two documents still being working on.  Two promised:  EPP over mail; EPP
push.  Also some murmur of new issues.  Could start considering because
base has been worked well.  Don't want to.  Will update milestones; only
one left is about to be accomplished.

---

Anyone have comments on containers?

Manley: Containers, at first and second glance, provide a lot of good
functionality.  For registrars, could help with transfers-able to transfer
an entire profile in a single command.  Could be scary on the server side.
Billing?  Objects could be in various states.  Makes it easy to change and
do mass changes.  I had some questions that were not all answered.

Tom McGarry:  We'll volunteer to do push.  Re: containers.  Not implemented
yet.  What are options other than standardize?

Lewis:  Experimental versus standards track.

McGarry:  Customers like the idea.

Wesson:  Not convinced that transfers and containers aren't a big security
issue.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

From: "James Woods" <[email-masked]>
To: <[email-masked]>
Subject: RE: Open Source Server Implementation
Date: Mon, 7 Jan 2002 17:39:23 -0500
Importance: Normal
Sender: [email-masked]

Hi Scott,

We have two EPP implementation services that we plan to launch soon,
(the openess is under debate right now but I think I'll win this one ;)
one is a modified client (ala GUI) called CuteEPP the other EPPserv.
Regardless of whether these get "opened" or not our dev team would love
to hook up with others wishing to do so.

I can be reached by : [email-masked]

Cheers,

James Woods

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hollenbeck, Scott
Sent: January 7, 2002 8:57 AM
To: [email-masked]'
Subject: Open Source Server Implementation

Is anyone aware of any efforts towards developing an open source EPP
server? I have implementers who are able and willing to contribute to a
collaborative effort, including contributing some of the code we've
developed.

-Scott- 

Date: Mon, 7 Jan 2002 10:02:33 -0500
To: "[email-masked]'" <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: RE: Requirements Document Update
Sender: [email-masked]

At 11:48 AM -0500 1/4/02, Hollenbeck, Scott wrote:
>More to the point, I think the intention is to ensure that IETF-specified
>protocol documents don't build on "problematic" transports.  Maybe Ed can
>provide more detail based on the exchange he had with Patrik.

Sorry, I can't.  When I asked about the motivation of the new text, I was
told it was to ensure (okay, require) that congestion control was part of
the transport.  My guess is that this is some concern that blew through the
IESG in response to some other networking technology, perhaps telephony
related.  But I am just guessing.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Opinions expressed are property of my evil twin, not my employer.

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Open Source Server Implementation
Date: Mon, 7 Jan 2002 08:56:47 -0500 
Sender: [email-masked]

Is anyone aware of any efforts towards developing an open source EPP server?
I have implementers who are able and willing to contribute to a
collaborative effort, including contributing some of the code we've
developed.

-Scott- 

Date: Mon, 7 Jan 2002 05:15:51 -0800
From: Bill Manning <[email-masked]>
To: Eric Brunner-Williams in Portland Maine <[email-masked]>
Cc: Bill Manning <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Requirements Document Update
Sender: [email-masked]

On Sun, Jan 06, 2002 at 04:42:44AM -0800, Eric Brunner-Williams in Portland Maine wrote:
> bill,
> 
> nice catch.
> this is boardering on goofy.

	Don't get me started.

> i think this is the first time i've seen the congestion control on this list.
> this means it is way out in left field.

	Nah, its just that I change hw frequently and the MUA is not
	always up to par.

> if someone finnished doing a transport mapping for smtp, and decided to
> write yet-another-mapping, for uucp (hint to self), the users would be as
> concerned with the ietf as ... any users of uucp.

	Ah, but then it would be in violation of the spec!

> 
> (still using uucp)
> eric
> wampumpeag, llc

Date: Sun, 06 Jan 2002 22:21:28 +0100 (MET)
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Requirements Document Update 
From: Lars-Johan Liman <[email-masked]>
Sender: [email-masked]

[email-masked]:
> i think this is the first time i've seen the congestion control on
> this list.  this means it is way out in left field.

> if someone finnished doing a transport mapping for smtp, and decided
> to write yet-another-mapping, for uucp (hint to self), the users
> would be as concerned with the ietf as ... any users of uucp.

It's just me on Christmas holiday. :-)

This list is "subscribers only" in the sense that Majordummy
implements it. Messages with "From:" matching any subscribed address
or one of the "golden VIP" addresses (like the IETF secretariat, the
area directors, me, other usual suspects ... ;-) are forwarded
immediately. If it doesn't match, it's sent to the moderators (Ed,
Jaap and me) for manual approval (or dismissal if it's pure
spam). Bill sent the message from a different address than the one
he's subscribed with, so it was caught in the moderators' filter
waiting for manual approval, which was done when I just happend to
take a peek in my mailbox, even though I'm on vacation. (Seems like Ed
and Jaap are too. ;-). This slows down a few messages, but believe me,
there's a fair amount of spam out there that _doesn't_ hit you thanks
to this.

So, if you want speedy transport, make sure you use the right sender
address. I'm of course quite willing to change the policy if there are
strong voices for it.

				Cheers,
				  /Liman
#----------------------------------------------------------------------
# Lars-Johan Liman		! E-mail: [email-masked]
# Senior Systems Specialist     ! HTTP  : //www.autonomica.se/
# Autonomica AB, Stockholm 	! Voice : +46 8 - 615 85 72
#----------------------------------------------------------------------

To: Bill Manning <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: Requirements Document Update 
Date: Sun, 06 Jan 2002 04:42:44 -0800
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Sender: [email-masked]

bill,

nice catch.

this is boardering on goofy.

i think this is the first time i've seen the congestion control on this list.
this means it is way out in left field.

if someone finnished doing a transport mapping for smtp, and decided to
write yet-another-mapping, for uucp (hint to self), the users would be as
concerned with the ietf as ... any users of uucp.

(still using uucp)
eric
wampumpeag, llc

Date: Fri, 4 Jan 2002 08:50:40 -0800
From: Bill Manning <[email-masked]>
To: "Hollenbeck, Scott" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Requirements Document Update
Sender: [email-masked]

> ago.  Here's a summary of the changes:
> 
> 1. Changed the last sentence in section 4.4.
> "The protocol SHOULD be serviceable over multiple standard communications
> protocols."
> 
> was changed to
> 
> "The protocol MUST only be run over IETF approved protocols that feature
> congestion control, such as TCP and SCTP."
> 
> -Scott- 

	So, the protcol is prohibited from running on non-IESG approved
	protocols?  How the heck are they going to enforce that?  
	
--bill

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Bill Manning'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Requirements Document Update
Date: Fri, 4 Jan 2002 11:48:21 -0500 
Sender: [email-masked]

> -----Original Message-----
> From: Bill Manning [mailto:[email-masked]]
> Sent: Friday, January 04, 2002 11:51 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]'
> Subject: Re: Requirements Document Update
>
>
> 	So, the protcol is prohibited from running on non-IESG approved
> 	protocols?  How the heck are they going to enforce that?  

Sounds like a job for the protocol police.... ;-)

More to the point, I think the intention is to ensure that IETF-specified
protocol documents don't build on "problematic" transports.  Maybe Ed can
provide more detail based on the exchange he had with Patrik.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Requirements Document Update
Date: Fri, 4 Jan 2002 08:51:33 -0500 
Sender: [email-masked]

Earlier this week Ed Lewis received some additional comments from the IESG
directed at draft-ietf-provreg-grrp-reqs-03.txt.  I've made the requested
changes, and sent an updated document to the I-D administrator a few moments
ago.  Here's a summary of the changes:

1. Changed the last sentence in section 4.4.
"The protocol SHOULD be serviceable over multiple standard communications
protocols."

was changed to

"The protocol MUST only be run over IETF approved protocols that feature
congestion control, such as TCP and SCTP."

2. More fixes to "may", "must", and "should".
Lower-case variants of these words were changed to alternate terms to avoid
confusion with directives described in RFC 2119.

3. Updated the "Acknowledgements" section.
I went through the list archives and collected the names of everyone who
provided commentary on the document.  This wasn't an IESG comment, but I
took the opportunity to get it done.

4. Separated references into normative and informative subsections.
The IESG apparently wants this sort of separation to help make normative
reference dependencies more clear.

-Scott-