Subject: RE: [ietf-provreg] EPP Document Updates

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 11 Jul 2005 20:56:23 +0200 (MEST)

Good catch -- thanks!

-Scott- 

> -----Original Message-----
> From: janusz [mailto:[email-masked]] 
> Sent: Monday, July 11, 2005 11:34 AM
> To: Hollenbeck, Scott; [email-masked]
> 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-
> >
> >  
> >
> 
> 
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 22 Jul 2005 17:43:38 +0200 (MEST)

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Friday, July 22, 2005 11:11 AM
> To: [email-masked]
> On Fri, Jul 22, 2005 at 09:57:32AM -0400, Edward Lewis wrote:
> > Does this need to be done in the protocol?  (One of my litmus test 
> > questions.)
> 
> I think it has to be _possible_ in the protocol, anyway; and today, I
> think, it isn't.  (I may be wrong, of course.  I'm always happy to be
> corrected.)

The problem I see with trying to match status values to object
attributes is that the attributes aren't static.  More can be added by
extension, and then what?  Do we need to go back and update the domain
mapping to deal with new extension attributes?  It makes much more sense
to deal with special cases using extensions.

Which leads me to this: there *is* a way to deal with this in the
protocol right now:

- Do not use serverUpdateProhibited at all if you wish to allow some
updates, but not others.

- Define an extension to add new status values that match local registry
update policy.

-Scott-