[ietf-provreg] EPP Document Updates

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

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-