Re: [eppext] New Version Notification for draft-brown-epp-reverse-00.txt

["Gould, James" <[e-mail]>]

Gavin,

I have not heard of the need for such a undue or reverse feature, but I’ll check to see whether this feature is useful with our product team.

From a protocol perspective, I have the same concern with this draft that I did with the original version of draft-ietf-eppext-keyrelay, where a protocol extension (reverse:reverse) is being mixed with an object extension (reverse:panData).  Mixing the two will result in urn:ietf:params:xml:ns:reverse-0.1 needing to be included as both a <svcExtension> and an <objURI> in the greeting and login packets and will require the use of two packet factories instead of one.  My recommendation is to handle it in a similar fashion with draft-ietf-eppext-keyrelay in using strictly an object extension, where reverse:create is used to submit the reversal request, with the option of including a concrete create response, and utilize the reverse:panData as is.  You could also support an info command and response to enable the client to determine the status of the reversal on demand.  I am somewhat concerned that no additional context (object and command) is provided other then the server transaction identifier.  The client does not state what the action was with the server transaction identifier and the server does not state anything about what was really undone.  What if the wrong transaction is undone and what if the transaction is not the latest one on the object?  I realize that the server transaction identifier is unique, but I wouldn’t want to make it too easy for inadvertent mistakes on an undue and I wouldn’t want to cause issues with the state of the object.

Thanks,


—


JG


[cid:[e-mail]]

James Gould
Distinguished Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On Nov 13, 2015, at 6:02 AM, Gavin Brown <[e-mail]<mailto:[e-mail]>> wrote:

Hi all,

I've just uploaded an I-D for a new EPP extension. From the Introduction:

  The Extensible Provisioning Protocol (EPP) provides a way for clients
  to create and update objects in a central repository.  Usually, the
  commands that a client sends to a server will have been initiated
  upon request of a human being.  As a result, occasionally a command
  is sent which contains an error. [...] The extension described in this
  document attempts to provide an additional remedy for [cases where
  the existing EPP command repertoire cannot be used] by providing a
  way for a client to request that a previous command be reversed.  In
  order to reverse a command, the client need only record the
  <svTRID> returned by the server in its response to the command.

Before starting work on this extension, I looked around to see if there
was anything similar already out there. Nominet have an extension which
allows clients to cancel <renew> commands[1] but I wasn't able to find
anything that implemented a general purpose "undo".

One thing on the roadmap is to add clarity about what should happen if
the client tries to <reverse> a command that is still pending (ie the
original command got a 1001 response). Otherwise I think most of the
bases have been covered.

Comments and suggestions welcome as always!

G.

[1]
http://registrars.nominet.org.uk/namespace/uk/registration-and-domain-management/epp-commands#Unrenew

--
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.
<New Version Notification for draft-brown-epp-reverse-00_txt.eml>_______________________________________________
EppExt mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/eppext