RE: [ietf-provreg] EPP Document Updates

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

Good catch -- thanks!

-Scott- 

> -----Original Message-----
> From: janusz [mailto:janusz@ca.afilias.info] 
> Sent: Monday, July 11, 2005 11:34 AM
> To: Hollenbeck, Scott; ietf-provreg@cafax.se
> Subject: Re: [ietf-provreg] EPP Document Updates
> 
> 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-
> >
> >  
> >
> 
> 
>