Subject: [ietf-provreg] EPP Document Updates

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 11 Jul 2005 16:34:57 +0200 (MEST)

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: janusz <[email-masked]>
Date: Mon, 11 Jul 2005 17:33:45 +0200 (MEST)

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

---

From: janusz <[email-masked]>
Date: Tue, 12 Jul 2005 18:08:04 +0200 (MEST)

>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

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 13 Jul 2005 19:18:17 +0200 (MEST)

My bet is that my From: address above doesn't match the one in the
subscriber's list, so I'm re-sending this with the old address
version.

Hi all,

On Mon, Jul 11, 2005 at 10:35:09AM -0400, Hollenbeck, Scott wrote:

> ambiguities been discovered?  

I've been working on an I-D detailing some of the Afilias experiences
with implementation.  I've unfortunately missed the most recent cut off,
but them's the breaks.  Once I've completed this, I'll be sure to
forward it here.  Aside from the three Scott mentioned, and the one
Janusz sent, I haven't run into any other outright conflicts; but I
do think that some improvements are needed, mostly having to do with
flexibility.  

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: Edward Lewis <[email-masked]>
Date: Tue, 19 Jul 2005 20:37:12 +0200 (MEST)

>There may be other possibilities.  Opinions?

I talked this over with the developers in-house - I'd (we'd) 
recommend altering the pendingDelete rule (first option).

For one, this minimizes the changes to the documented specificiations 
(and hence code).

And, stepping back a bit, why have a "pendingX" if X can't be 
prevented?  (I understand that there may be latency in doing X, but 
as far as a protocol like EPP is concerned, why distinguish the 
pending state?)

>create a new working group if significant issues are identified.

Do you think that this change needs a re-spin at PS?  (Not that it 
matters much, the "6-month delay" required as *one* of the steps to 
DS was spent in the RFC editor queue last time we made it to PS. ;) ) 
Maybe with a change like this we ought to dub it EPP 1.1.

BTW - I've seen references to EPP "v6".  I'm assuming that that is 
the -06 drafts, not a successor to the RFC version nor EPP for IPv6.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.