Edward Lewis | 1 Jun 23:39 2003
Picon

provreg - another document for IESG consideration

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.

Internet-Drafts | 2 Jun 13:29 2003
Picon

I-D ACTION:draft-ietf-provreg-epp-ext-03.txt

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

	Title		: 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
(Continue reading)

The IESG | 2 Jun 16:50 2003
Picon

Protocol Action: Extensible Provisioning Protocol to Proposed Standard


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.

   
(Continue reading)

Edward Lewis | 2 Jun 22:48 2003
Picon

Milestone update

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.

hardie | 3 Jun 00:00 2003

Re: Milestone update

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.

Edward Lewis | 9 Jun 18:40 2003
Picon

group status

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
(Continue reading)

The IESG | 16 Jun 21:52 2003
Picon

Document Action: Guidelines for Extending the Extensible Provisioning Protocol to Informational


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

The IESG | 17 Jun 22:07 2003
Picon

Document Action: Guidelines for Extending the Extensible Provisioning Protocol to Informational


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

Bernie Hoeneisen | 27 Jun 15:20 2003
Picon

Some EPP questions

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
     ___________________________________

(Continue reading)

Hollenbeck, Scott | 30 Jun 19:43 2003
Picon

RE: Some EPP 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?

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.

> 2) epp-09, 3; epp-09, 2.9.3.4; epp-domain-07, 3.2.4; 
(Continue reading)


Gmane