Subject: [ietf-provreg] Some EPP questions

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 27 Jun 2003 15:20:02 +0200 (CEST)

Hi EPPers!

Trying to get familiar with EPP I have the following questions:

1) epp-09, 2.9.3.4:

   In the transfer command, there is a command attribute 'op=__' defined,
   which can take values 'request', 'cancel', 'approve', 'reject',
   'query'. In other transform commands such as 'delete', 'create', or
   'update' no such 'op=__' attribute is defined.

   An example, where an "op=cancel" command attibute for a delete request
   is useful, could be:

   A domain object is in a pendingDelete state, and the holder changes his
   mind (he wants to keep the domain name). In this case I see no EPP
   mechanism for the registrar to interact, i.e. cancel the delete
   request. Also an "op=query" to figure out the state of the request
   could be useful in such a case.

   What is the reason, why the same command attributes 'op=cancel', etc.
   are not foreseen for other transform commands?

2) epp-09, 3; epp-09, 2.9.3.4; epp-domain-07, 3.2.4; epp-contact-07, 3.2.4

   In section 3 (epp-09), in the result codes it is described:

     Code    Response text in English
     ___________________________________

     1000    "Command completed successfully"
     This is the usual response code for a successfully completed
     command that is not addressed by any other 1xxx-series response
     code.

     1001    "Command completed successfully; action pending"
     This response code MUST be returned when responding to a command
     the requires offline activity before the requested action can be
     completed.  See section 2 for a description of other processing
     requirements.

   In the examples epp-09, 2.9.3.4; epp-domain-07, 3.2.4; epp-contact-07,
   3.2.4, (transfer command) the result code is "1000", although further
   below there is <obj:trStatus>pending</obj:trStatus>.

   What is the idea behind, that the response to the transfer command is
   labled as 'completed successfully', but on the other hand it is
   pending?

3) epp-contact-07

   I am a bit confused about the meaning of the 'roid' and the
   'contact-id'.  If I understood correctly, the only difference is, that
   the client can choose and propose a contact-id, which has to be
   available at the server, and the roid is assigned uniquely by the
   server.

   What is/are the reason/s that we have two identifiers for almost the
   same thing?

4) epp-host-07, 3.2.5

   According to section 3.2.5, a host object can be renamed. There is also
   something about other objects that refer to the host object:

     Host name changes can have an impact on associated objects that refer
     to the host object.  A host name change SHOULD NOT require additional
     updates of associated objects to preserve existing associations [...]

   It is not clear to me, what is meant here: Should a host object not be
   renamed, in case such associations remain, or are domain objects with
   associations updated implicitly together with a host name change?

Thanks in advance for your answers,
and sorry for possible "new-by" annoyance...:-)

cheers,
 Bernie

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 30 Jun 2003 13:43:26 -0400

>    are not foreseen for other transform commands?

All of the pother commands are typically processed in real time without
cross-client interaction.  A transfer requires action from a second client.
We debated the merits of allowing cancels of deletes etc., but I for one
thought such facilities out of place for commands that don't require action
from a second client.

>      Code    Response text in English

The difference is in command processing vs. action completion.  When a
command is received and processed successfully, you get the 1000 response
code.  When something has to happen out-of-band, you get the 1001 response.
1001 means that command has been received and processed, but some action
related to the command wasn't completed before the response was sent.
 
>    What is/are the reason/s that we have two identifiers for 

Some people felt that we needed a globally-unique identifier (the ROID) in
addition to the server-unique identifier (the contact-id).  There was a
lengthy debate that's documented in the mailing list archives.

>    associations updated implicitly together with a host name change?

When a host object is renamed, the associations to that object (such as name
server delegations) should be updated automatically as needed.

-Scott-

From: "Hollenbeck, Scott" <[email-masked]>
To: "'Bernie Hoeneisen'" <[email-masked]>, [email-masked]
Subject: RE: [ietf-provreg] Some EPP questions
Date: Mon, 30 Jun 2003 13:43:26 -0400
Sender: [email-masked]

>    are not foreseen for other transform commands?

All of the pother commands are typically processed in real time without
cross-client interaction.  A transfer requires action from a second client.
We debated the merits of allowing cancels of deletes etc., but I for one
thought such facilities out of place for commands that don't require action
from a second client.

>      Code    Response text in English

The difference is in command processing vs. action completion.  When a
command is received and processed successfully, you get the 1000 response
code.  When something has to happen out-of-band, you get the 1001 response.
1001 means that command has been received and processed, but some action
related to the command wasn't completed before the response was sent.
 
>    What is/are the reason/s that we have two identifiers for 

Some people felt that we needed a globally-unique identifier (the ROID) in
addition to the server-unique identifier (the contact-id).  There was a
lengthy debate that's documented in the mailing list archives.

>    associations updated implicitly together with a host name change?

When a host object is renamed, the associations to that object (such as name
server delegations) should be updated automatically as needed.

-Scott-

Date: Fri, 27 Jun 2003 15:20:02 +0200 (CEST)
From: Bernie Hoeneisen <[email-masked]>
To: [email-masked]
Subject: [ietf-provreg] Some EPP questions
Sender: [email-masked]

Hi EPPers!

1) epp-09, 2.9.3.4:

3) epp-contact-07

4) epp-host-07, 3.2.5

cheers,
 Bernie

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: [ietf-provreg] Document Action: Guidelines for Extending the Extensible  Provisioning Protocol to Informational
Date: Tue, 17 Jun 2003 16:07:01 -0400
Sender: [email-masked]

The IESG has approved the Internet-Draft 'Guidelines for Extending the 
Extensible Provisioning Protocol' <draft-ietf-provreg-epp-ext-03.txt> 
as an Informational RFC.  This document is the product of the 
Provisioning Registry Protocol Working Group.  The IESG contact 
persons are Ned Freed and Ted Hardie.

RFC-Editor,
                 Please remove section 7.0, the acknowledgements
 from this draft. This section was retained through
 the process should substantive comments be received,
 but none of note were.
                                                 thanks,
                                                 Ted Hardie

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: [ietf-provreg] Document Action: Guidelines for Extending the Extensible  Provisioning Protocol to Informational
Date: Mon, 16 Jun 2003 15:52:18 -0400
Sender: [email-masked]

The IESG has approved the Internet-Draft 'Guidelines for Extending the 
Extensible Provisioning Protocol' <draft-ietf-provreg-epp-ext-04.txt> 
as an Informational RFC.  This document is the product of the 
Provisioning Registry Protocol Working Group.  The IESG contact 
persons are Ned Freed and Ted Hardie.

RFC-Editor,
                 Please remove section 7.0, the acknowledgements
 from this draft. This section was retained through
 the process should substantive comments be received,
 but none of note were.
                                                 thanks,
                                                 Ted Hardie

Date: Mon, 9 Jun 2003 12:40:49 -0400
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] group status
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Where is the group?
===================

We are not planning to have a meeting in Vienna.

We have 1 RFC done already, 5 in the RFC editor's queue, and our 
other document is in "Publication Requested" state.  The latter is on 
the agenda of the next IESG meeting.

We have completed all our milestones, all we are waiting for now is 
to see the last document become published as an RFC.

Unless someone has any bright ideas.

Where will that leave us?
=========================

EPP will be a proposed standard protocol, with one supporting 
document describing the process of extending it.

RFC 2026 says this about proposed standards:

    A Proposed Standard specification is generally stable, has resolved
    known design choices, is believed to be well-understood, has received
    significant community review, and appears to enjoy enough community
    interest to be considered valuable.  However, further experience
    might result in a change or even retraction of the specification
    before it advances.

and

    Implementors should treat Proposed Standards as immature
    specifications.  It is desirable to implement them in order to gain
    experience and to validate, test, and clarify the specification.
    However, since the content of Proposed Standards may be changed if
    problems are found or better solutions are identified, deploying
    implementations of such standards into a disruption-sensitive
    environment is not recommended.

What this means is that even if the WG folds it's tent at this point, 
there is still work to do (in the eyes of the IETF machinery), which 
is to get to the next level (Draft Standard).  It is up to the 
interested community to keep this going, just as it has gotten us to 
the level we are approaching now.  When the time comes and the desire 
is there, a new WG would be needed to review the Draft Standard 
version of the documents.  That WG will be formed much in the same 
way this WG was formed in 2000/2001.

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

Okay, okay, the previous sig wasn't all that good...

Date: Mon, 2 Jun 2003 15:00:52 -0700
To: Edward Lewis <[email-masked]>
From: [email-masked]
Subject: Re: [ietf-provreg] Milestone update
Cc: Edward Lewis <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Ed,
	I have marked the draft as "publication requested", and
I expect to have it on the IESG agenda prior to the Vienna meeting.
If you would like to update the charter to mark the item done
(since it has been submitted), that's fine by me.  I don't think
you need a placeholder item; the default item for working
groups at this stage is essentially "sticking around to respond
to questions that come up from Last Call, the IESG, or the
RFC-Editor".  Since this is informational, I wasn't planning to
issue a Last Call, but the others apply.
			regards,
				Ted Hardie

At 2:48 PM -0600 6/2/03, Edward Lewis wrote:
>I'd like to get this marked as Done...
>
># May 03  Submit Guidelines for Extending the EPP to IESG (Informational)
>
>I don't know (Ted) if we need a placeholder to respond to IESG 
>comments on that submission.
>--
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>Edward Lewis                                            +1-703-227-9854
>ARIN Research Engineer
>
>Digital cameras are to film cameras as Etch-A-Sketches are to canvases.

Date: Mon, 2 Jun 2003 14:48:23 -0600
To: [email-masked]
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] Milestone update
Cc: Ted Hardie <[email-masked]>, Edward Lewis <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

I'd like to get this marked as Done...

# May 03  Submit Guidelines for Extending the EPP to IESG (Informational)

I don't know (Ted) if we need a placeholder to respond to IESG 
comments on that submission.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Digital cameras are to film cameras as Etch-A-Sketches are to canvases.

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>, Internet Architecture Board <[email-masked]>, [email-masked]
From: The IESG <[email-masked]>
Subject: [ietf-provreg] Protocol Action: Extensible Provisioning Protocol to Proposed Standard
Date: Mon, 02 Jun 2003 10:50:20 -0400
Sender: [email-masked]

The IESG has approved the following Internet-Drafts as Proposed
Standards:

 o Extensible Provisioning Protocol
	<draft-ietf-provreg-epp-09.txt> 
 o Extensible Provisioning Protocol Domain Name Mapping
	<draft-ietf-provreg-epp-domain-07.txt>
 o Extensible Provisioning Protocol Host Mapping
	<draft-ietf-provreg-epp-host-07.txt> 
 o Extensible Provisioning Protocol Contact Mapping
	<draft-ietf-provreg-epp-contact-07.txt>
 o Extensible Provisioning Protocol Transport Over TCP
	<draft-ietf-provreg-epp-tcp-06.txt>

These documents are the product of the Provisioning Registry Protocol
Working Group.  The IESG contact persons are Ned Freed and Patrik
Faltstrom.

Technical Summary
   
These documents describes an application layer client-server protocol 
for the provisioning and management of objects stored in a shared 
central repository. Specified in XML, the protocol defines generic 
object management operations and an extensible framework that maps 
protocol operations to objects. Further, object definitions of a few 
objects needed for domain name registration and a binding to TCP as 
transport protocl is provided.

Working Group Summary
   
There has been discussions in the wg whether the binding to TCP should 
be the only binding, whether other bindings like SMTP and Beep is 
"better" or "required" and during last call whether the protcol 
itself should be asynchronous or not.

Result of these discussions ended up with TCP as one extension 
mechanism of many possible ones (SMTP and Beep bindings in separate 
documents), and that the protocol itself should be synchronous. This 
last point make the protocol simpler, but will possibly make some 
bindings more complicated.

The changes had concensus in the working group, and resulted in the 
version of the documents which are now approved.

Protocol Quality
   
The specification has been reviewed by Patrik Faltstrom for the IESG.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-ext-03.txt
Date: Mon, 02 Jun 2003 07:29:37 -0400
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		: Guidelines for Extending the Extensible Provisioning 
                          Protocol
	Author(s)	: S. Hollenbeck
	Filename	: draft-ietf-provreg-epp-ext-03.txt
	Pages		: 19
	Date		: 2003-5-30
	
The Extensible Provisioning Protocol (EPP) is an application layer
client-server protocol for the provisioning and management of objects
stored in a shared central repository.  Specified in XML, the
protocol defines generic object management operations and an
extensible framework that maps protocol operations to objects.  This
document presents guidelines for use of EPP's extension mechanisms to
define new features and object management capabilities.

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

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

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

--OtherAccess--

--NextPart--

Date: Sun, 1 Jun 2003 15:39:14 -0600
To: Ted Hardie <[email-masked]>
From: Edward Lewis <[email-masked]>
Subject: [ietf-provreg] provreg - another document for IESG consideration
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Ted,

The WG would like the IESG to consider the following document for 
Informational.

      Guidelines for Extending the Extensible Provisioning Protocol
                    draft-ietf-provreg-epp-ext-03.txt

Link:
   http://www.ietf.org/internet-drafts/draft-ietf-provreg-epp-ext-03.txt

I haven't seen the announcement of this document yet, but it is available.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Digital cameras are to film cameras as Etch-A-Sketches are to canvases.