Re: [ietf-provreg] EPP Document Updates

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

Hollenbeck, Scott wrote:

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

I see another way of resolving the conflict between 3731 and 3915 
documents. The approach could eliminate any need for exceptions related 
to pending status values. Unfortunatelly more changes to both 3731 and 
3915 would be necessary. Here is how it would work.

A mechanism could be introduced for all commands that may result in 
"pending action" to at least cancel the pending state. Such mechanism is 
already defined for transfer command as "op" attribute. With some 
adjustments the transfer mechanism based on "op" attribute could be 
"reused" for create, update, delete and renew commands.  To minimize 
impact on existing EPP implementations the attribute  could be OPTIONAL 
with default value "request".

After introducing "op" attribute to at least delete command 3915 
document can be modified to define rgp restore request as an extension 
to delete command instead of update. The request would look like:

<command>
<delete op="cancel">
   ...
</delete>
<extension>
  <rgp:delete>
  </rgp:delete>
</extension>
</command>

The proposed cancellation mechanism would eliminate not just the 
conflict between 3731 and 3915 but also any similiar conflict in the 
future. The mechanism could also improve protocol architecture by 
restoring some symetry between  transfer and (create, update, delete, 
renew) commands.

Janusz Sienkiewicz