Statements of EPP "missing methods"

["Scott Hollenbeck" <sah@xxxxxxxxxxxxxxx>]

I am sending this comment as the original designer and author of the
Extensible Provisioning Protocol (EPP).  In the interest of full disclosure
I must also note that I am employed by VeriSign, a company that has
submitted a competing proposal for the administration of .net.

The proposal submitted by Asociación CORE++ includes this statement:

"EPP 1.0 is missing methods that allow the registrar to determine the
outcome of a command in case of a communication interruption during an
ongoing transaction. With the proposed extension, registrars are able for
the first time to implement a generic and simple algorithm to handle this
situation. The command extension uses the client transaction ID that can be
supplied by the registrar. It either returns the result of the command where
this transaction ID has been used or the notice that no such command has
been received by the registry in a certain time frame. Based on this, the
registrar can easily decide whether he needs to resubmit the interrupted
command or not."

The lack of this "feature" is the result of an explicit design decision made
by the Internet Engineering Task Force (IETF) "provreg" working group that
finalized the design of EPP.  Early draft versions of EPP included a
<status> command to determine the outcome of other commands, but this
command was removed from the protocol as a result of open discussion within
the working group.  The decision to do so is documented in the archives of
the working group mailing list:

http://www.cafax.se/ietf-provreg/maillist/2002-07/msg00072.html

This decision was not reached without considerable debate.  In the end,
though, the working group reached a consensus position that EPP's command
idempotency provides the assurance that there is no harm in resending any
command for which the client is unsure of the server's response.

The proposed new feature adds an additional, unnecessary algorithm.  If a
registrar is ever unsure that a command has been received and processed, it
needs do nothing more than resend the same command and check the standard
response code.  A positive response to the second command would indicate
that the first was not processed successfully.  An error response to the
second command would indicate that the first was processed successfully.

An evaluator should consider the practical implications of implementing this
proposed feature.  For it to work properly, several factors would need to be
considered.  The result of processing each command sent to the registry will
have to be maintained either in perpetuity or for some defined period of
time.  The current .net registry operator processes many millions of
transactions per day, so the amount of data to be archived is significant.
EPP client transaction identifiers are not guaranteed to be unique.  How
will the results of these transactions be archived for use in real time?
How long will the results be maintained for real time checking?  How will
potentially ambiguous client transaction identifiers be distinguished by the
server?  Issues like these contributed greatly to the provreg working
group's decision to abandon the EPP <status> command.

The proposal submitted by Asociación CORE++ also includes this statement:

"These experiences either discovered shortcomings of the EPP protocol or
proved doubts that have been expressed by CORE++ members in the related IETF
ProvReg working group, but have been rejected due to a too registry centric
view or lack of farsightedness demonstrated by members of the working
group."

EPP is what it is today as a result of the consensus policies of the IETF
and the lengthy discussions that took place within the provreg working
group.  Some proposals survive the consensus building process.  Some do not.
The <status> command proposal did not, for very legitimate reasons.  Please
consider this fact as you evaluate the statements made in this proposal.

Thank you for the opportunity to provide these comments.

Scott Hollenbeck
Author and Editor, the Extensible Provisioning Protocol
Member of the IETF provreg Working Group