RE: [ietf-provreg] Some EPP questions

["Hollenbeck, Scott" <[e-mail]>]

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

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

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.

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

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

-Scott-




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5UKlYmb025723 for <[e-mail]>; Mon, 30 Jun 2003 22:47:34 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5UKlXoJ025722 for ietf-provreg-outgoing; Mon, 30 Jun 2003 22:47:33 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5UKlVmb025717 for <[e-mail]>; Mon, 30 Jun 2003 22:47:32 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.9/8.12.9) with ESMTP id h5UKlUL4050448 for <[e-mail]>; Mon, 30 Jun 2003 22:47:30 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.9/8.12.6/Submit) id h5UKlSZX050447 for [e-mail]; Mon, 30 Jun 2003 22:47:28 +0200 (CEST)
Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5UHhQmb023875 for <[e-mail]>; Mon, 30 Jun 2003 19:43:27 +0200 (MEST)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.9/8.12.9) with ESMTP id h5UHiodr008215; Mon, 30 Jun 2003 13:44:50 -0400 (EDT)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2653.19) id <J8TXRTM2>; Mon, 30 Jun 2003 13:43:25 -0400
Message-ID: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: "'Bernie Hoeneisen'" <[e-mail]>, [e-mail]
Subject: RE: [ietf-provreg] Some EPP questions
Date: Mon, 30 Jun 2003 13:43:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

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

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

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.

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

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

-Scott-



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5UD9Pmb020654 for <[e-mail]>; Mon, 30 Jun 2003 15:09:25 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5UD9PB6020653 for ietf-provreg-outgoing; Mon, 30 Jun 2003 15:09:25 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5UD9Nmb020648 for <[e-mail]>; Mon, 30 Jun 2003 15:09:23 +0200 (MEST)
Received: from bartok.sidn.nl (localhost.sidn.nl [IPv6:::1]) by bartok.sidn.nl (8.12.9/8.12.9) with ESMTP id h5UD9ML4048124 for <[e-mail]>; Mon, 30 Jun 2003 15:09:22 +0200 (CEST) (envelope-from [e-mail])
Received: (from jaap@localhost) by bartok.sidn.nl (8.12.9/8.12.6/Submit) id h5UD9MkD048123 for [e-mail]; Mon, 30 Jun 2003 15:09:22 +0200 (CEST)
Received: from central.switch.ch (central.switch.ch [130.59.4.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5RDL7mb017812 for <[e-mail]>; Fri, 27 Jun 2003 15:21:09 +0200 (MEST)
Received: from machb.switch.ch ([130.59.4.143]) by central.switch.ch with esmtp (Exim 3.20 #1) id 19Vt9p-0005Nr-00; Fri, 27 Jun 2003 15:20:53 +0200
Date: Fri, 27 Jun 2003 15:20:02 +0200 (CEST)
From: Bernie Hoeneisen <[e-mail]>
To: [e-mail]
Subject: [ietf-provreg] Some EPP questions
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5HK77mb004433 for <[e-mail]>; Tue, 17 Jun 2003 22:07:07 +0200 (MEST)
Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5HK76PC004432 for ietf-provreg-outgoing; Tue, 17 Jun 2003 22:07:07 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5HK74mb004427 for <[e-mail]>; Tue, 17 Jun 2003 22:07:05 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08506; Tue, 17 Jun 2003 16:07:01 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>, Internet Architecture Board <[e-mail]>, [e-mail]
From: The IESG <[e-mail]>
Subject: [ietf-provreg] Document Action: Guidelines for Extending the Extensible  Provisioning Protocol to Informational
Date: Tue, 17 Jun 2003 16:07:01 -0400
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5GJqOmb018339 for <[e-mail]>; Mon, 16 Jun 2003 21:52:24 +0200 (MEST)
Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h5GJqN4c018338 for ietf-provreg-outgoing; Mon, 16 Jun 2003 21:52:23 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h5GJqMmb018333 for <[e-mail]>; Mon, 16 Jun 2003 21:52:22 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28643; Mon, 16 Jun 2003 15:52:18 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>, Internet Architecture Board <[e-mail]>, [e-mail]
From: The IESG <[e-mail]>
Subject: [ietf-provreg] Document Action: Guidelines for Extending the Extensible  Provisioning Protocol to Informational
Date: Mon, 16 Jun 2003 15:52:18 -0400
Sender: [e-mail]
Precedence: bulk

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h59Genmb015953 for <[e-mail]>; Mon, 9 Jun 2003 18:40:49 +0200 (MEST)
Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h59GenfE015952 for ietf-provreg-outgoing; Mon, 9 Jun 2003 18:40:49 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h59Gemmb015947 for <[e-mail]>; Mon, 9 Jun 2003 18:40:49 +0200 (MEST)
Received: by smtp1.arin.net (Postfix, from userid 5003) id 0F2D43A1; Mon,  9 Jun 2003 12:40:48 -0400 (EDT)
Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 934FF38E; Mon,  9 Jun 2003 12:40:47 -0400 (EDT)
Received: from [127.0.0.1] (HELO [192.168.1.100]) by arin.net (CommuniGate Pro SMTP 4.1b7) with ESMTP id 371962; Mon, 09 Jun 2003 12:38:13 -0400
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0cbb0a66db953e@[192.168.1.100]>
Date: Mon, 9 Jun 2003 12:40:49 -0400
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] group status
Cc: [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_01_02 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

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

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h52M16SX017857 for <[e-mail]>; Tue, 3 Jun 2003 00:01:06 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h52M16FF017856 for ietf-provreg-outgoing; Tue, 3 Jun 2003 00:01:06 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h52M14SX017851 for <[e-mail]>; Tue, 3 Jun 2003 00:01:05 +0200 (MEST)
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h52M0xXF025200 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 2 Jun 2003 15:01:00 -0700 (PDT)
Received: from [129.46.227.161] (carbuncle.qualcomm.com [129.46.227.161]) by sabrina.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h52M0vBC007407; Mon, 2 Jun 2003 15:00:57 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06001208bb0177bfae4f@[129.46.227.161]>
In-Reply-To: <a05111b0ebb016815999f@[192.35.165.240]>
References: <a05111b11bae05959ba60@[192.149.252.108]> <a05111b0ebb016815999f@[192.35.165.240]>
Date: Mon, 2 Jun 2003 15:00:52 -0700
To: Edward Lewis <[e-mail]>
From: [e-mail]
Subject: Re: [ietf-provreg] Milestone update
Cc: Edward Lewis <[e-mail]>, [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk

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                                            [phone]
>ARIN Research Engineer
>
>Digital cameras are to film cameras as Etch-A-Sketches are to canvases.



Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h52KmZSX017123 for <[e-mail]>; Mon, 2 Jun 2003 22:48:35 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h52KmZ3f017122 for ietf-provreg-outgoing; Mon, 2 Jun 2003 22:48:35 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h52KmYSX017114 for <[e-mail]>; Mon, 2 Jun 2003 22:48:35 +0200 (MEST)
Received: by smtp1.arin.net (Postfix, from userid 5003) id DC554347; Mon,  2 Jun 2003 16:48:31 -0400 (EDT)
Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 8DFB3321; Mon,  2 Jun 2003 16:48:31 -0400 (EDT)
Received: from [127.0.0.1] (HELO [192.35.165.240]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 341539; Mon, 02 Jun 2003 16:46:29 -0400
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b0ebb016815999f@[192.35.165.240]>
In-Reply-To: <a05111b11bae05959ba60@[192.149.252.108]>
References: <a05111b11bae05959ba60@[192.149.252.108]>
Date: Mon, 2 Jun 2003 14:48:23 -0600
To: [e-mail]
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] Milestone update
Cc: Ted Hardie <[e-mail]>, Edward Lewis <[e-mail]>, [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,IN_REP_TO,REFERENCES,SIGNATURE_SHORT_SPARSE, SPAM_PHRASE_00_01 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

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

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


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h52EoPSX013306 for <[e-mail]>; Mon, 2 Jun 2003 16:50:25 +0200 (MEST)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.9/8.12.9/Submit) id h52EoPHF013305 for ietf-provreg-outgoing; Mon, 2 Jun 2003 16:50:25 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h52EoOSX013300 for <[e-mail]>; Mon, 2 Jun 2003 16:50:24 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10431; Mon, 2 Jun 2003 10:50:20 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>, Internet Architecture Board <[e-mail]>, [e-mail]
From: The IESG <[e-mail]>
Subject: [ietf-provreg] Protocol Action: Extensible Provisioning Protocol to Proposed Standard
Date: Mon, 02 Jun 2003 10:50:20 -0400
Sender: [e-mail]
Precedence: bulk

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.


Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h52BTfSX011292 for <[e-mail]>; Mon, 2 Jun 2003 13:29:41 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h52BTfJD011291 for ietf-provreg-outgoing; Mon, 2 Jun 2003 13:29:41 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h52BTdSX011286 for <[e-mail]>; Mon, 2 Jun 2003 13:29:40 +0200 (MEST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01774; Mon, 2 Jun 2003 07:29:37 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: [ietf-provreg] I-D ACTION:draft-ietf-provreg-epp-ext-03.txt
Date: Mon, 02 Jun 2003 07:29:37 -0400
Sender: [e-mail]
Precedence: bulk

--NextPart

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

	Title		: 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:
	[e-mail].
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="[e-mail]"

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

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:	<[e-mail]>

--OtherAccess--

--NextPart--




Return-Path: <[e-mail]>
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h51LdMSX004888 for <[e-mail]>; Sun, 1 Jun 2003 23:39:22 +0200 (MEST)
Received: by nic.cafax.se (8.12.9/8.12.9/Submit) id h51LdMjC004887 for ietf-provreg-outgoing; Sun, 1 Jun 2003 23:39:22 +0200 (MEST)
X-Authentication-Warning: nic.cafax.se: majordom set sender to [e-mail] using -f
Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by nic.cafax.se (8.12.9/8.12.9) with ESMTP id h51LdKSX004882 for <[e-mail]>; Sun, 1 Jun 2003 23:39:21 +0200 (MEST)
Received: by smtp1.arin.net (Postfix, from userid 5003) id E80AA362; Sun,  1 Jun 2003 17:39:19 -0400 (EDT)
Received: from arin.net (mta.arin.net [192.136.136.126]) by smtp1.arin.net (Postfix) with ESMTP id 9378A35A; Sun,  1 Jun 2003 17:39:19 -0400 (EDT)
Received: from [127.0.0.1] (HELO [192.35.165.240]) by arin.net (CommuniGate Pro SMTP 4.1b6) with ESMTP id 339876; Sun, 01 Jun 2003 17:37:22 -0400
Mime-Version: 1.0
X-Sender: edlewis@127.0.0.1
Message-Id: <a05111b01bb00228850f7@[192.35.165.240]>
Date: Sun, 1 Jun 2003 15:39:14 -0600
To: Ted Hardie <[e-mail]>
From: Edward Lewis <[e-mail]>
Subject: [ietf-provreg] provreg - another document for IESG consideration
Cc: [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,SIGNATURE_SHORT_SPARSE,SPAM_PHRASE_00_01 version=2.43-arin1
X-Spam-Level: 
Sender: [e-mail]
Precedence: bulk

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

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