Re: [ietf-provreg] EPP Document Updates

[janusz <janusz@ca.afilias.info>]

There is probably a small error in contact transfer sample response 
(section 3.2.4 EPP  of RFC 3733, page 22). Element <result> in the 
sample response does not reflect pending action. The current sample 
response is inconsistent with relevant sample response for domain object 
mapping (section 3.2.4 of RFC 3731, page 26).

Janusz Sienkiewicz


Hollenbeck, Scott wrote:

>I recently received some information that prompts me to ask this group a
>question about the need to update one or more of the EPP RFCs.  This
>isn't at all unusual.  After all, "Proposed Standard" implies that
>implementation experience may uncover issues that went undetected during
>the usual working group and IETF review processes.  There is one issue
>with the working group documents that I already know about.
>
>RFC 3730 (EPP core):
>http://www.cafax.se/ietf-provreg/maillist/2004-11/msg00005.html
>This is an error in the descriptive text and an error in an example.
>
>In addition, I've been advised of other issues in two individual
>submission extension documents I wrote.  While not working group
>documents, these should also be revised if any changes are made to the
>core document(s):
>
>RFC 4114 (ENUM extension to RFC 3731 (the domain mapping)):
>http://www1.ietf.org/mail-archive/web/enum/current/msg03654.html
>This is an error in an example.
>
>RFC 3915 (ICANN RGP extension to RFC 3731):
>I don't believe that this one has been described on-list, so here it is.
>RFC 3731 says this:
>
>"With one exception, transform commands MUST be rejected when a
>pendingCreate, pendingDelete, pendingRenew, pendingTransfer, or
>pendingUpdate status is set.  The only exception is that a <transfer>
>command to approve, reject, or cancel a transfer MAY be processed while
>an object is in "pendingTransfer" status."
>
>As defined by ICANN, the redemption grace period starts when a domain
>has entered pendingDelete status after expiration.  According to 3731,
>this means that no <domain:update> transform operations are allowed.
>3915 uses an extended <domain:update> command to "restore" a domain
>before it can be deleted.  This appears to cause a conflict with the
>"MUST be rejected" specified in 3731.
>
>This can be addressed in a few different ways:
>
>- Modify 3731 to change the pendingDelete rule in a
>non-RGP-extension-specific way.
>- Modify 3915 to note that the extended <domain:update> is an exception
>to the pendingDelete rule.  This was my original intention, but I agree
>that it's not clearly specified that way.  Section 4.2.5 already does
>this for a related update situation.
>- Modify 3915 extensively to perform RGP processing some other way.
>
>There may be other possibilities.  Opinions?
>
>So, this is a request for information.  Have any other conflicts or
>ambiguities been discovered?  Depending on what we find we may be able
>to move the documents to Draft Standard status by making editorial
>changes (such as fixing examples).  Protocol changes (text or XML
>Schema) typically require a re-spin at Proposed Standard before they can
>be advanced to Draft.  Applications AD Ted Hardie can provide more
>guidance once we know what needs to be changed.  We might even need to
>create a new working group if significant issues are identified.
>
>-Scott-
>
>  
>