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

From: Gavin Brown <[email-masked]>
Date: Fri, 13 Nov 2015 11:02:01 +0000

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.

Subject: New Version Notification for draft-brown-epp-reverse-00.txt
From: [email-masked]
To: "Gavin Brown" <[email-masked]>, "Jothan Frakes" <[email-masked]>
Date: Fri, 13 Nov 2015 02:45:09 -0800

A new version of I-D, draft-brown-epp-reverse-00.txt
has been successfully submitted by Gavin Brown and posted to the
IETF repository.

Name:		draft-brown-epp-reverse
Revision:	00
Title:		Command Reversal Extension for the Extensible Provisioning Protocol (EPP)
Document date:	2015-11-13
Group:		Individual Submission
Pages:		9
URL:            https://www.ietf.org/internet-drafts/draft-brown-epp-reverse-00.txt
Status:         https://datatracker.ietf.org/doc/draft-brown-epp-reverse/
Htmlized:       https://tools.ietf.org/html/draft-brown-epp-reverse-00

Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   extension mapping for reversing previous EPP commands.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Volker Janzen Notify <[email-masked]>
Date: Fri, 13 Nov 2015 12:16:07 +0100

Hi Gavin,

On 11/13/2015 12:02 PM, Gavin Brown wrote:
> In order to reverse a command, the client need only record the

is there a solution in case of the client was not able to receive the
answer due to a network error? These commands might not be undone
without the knowledge of the svTRID.

> I wasn't able to find anything that implemented a general purpose "undo".

I'm not sure if I've seen anything like this, except for the "undo"
renew from Nominet.

In general delete will "undo" create, changes due to an update can be
reverted by another update. There is nothing to "undo" a renew, but this
might be nice, if you've added to many years. Would not allow it if the
expire gets to old by the undo.

Volker Janzen
Team Entwicklung

-- 
InterNetX GmbH
Maximilianstr. 6
93047 Regensburg
Germany

Tel: +49 941 59559-0
Fax: +49 941 59579-050

www.internetx.com
www.facebook.com/InterNetX
www.twitter.com/InterNetX

Geschäftsführer/CEO: Thomas Mörz
Amtsgericht Regensburg, HRB 7142

---

From: "Gould, James" <[email-masked]>
Date: Fri, 13 Nov 2015 13:59:30 +0000

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

James Gould
Distinguished Engineer
[email-masked]

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

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

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

Hi all,

G.

[1]

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
[email-masked]
https://www.ietf.org/mailman/listinfo/eppext

---

From: Gavin Brown <[email-masked]>
Date: Tue, 17 Nov 2015 18:07:06 +0000

Hi Jim, thanks for the feedback.

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

We (CentralNic) frequently have to deal with requests from registrars
where they have accidentally renewed a domain for too many years. Rather
than just meet this need, I wanted to create an extension that had a
wider scope.

> 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).

I am not aware of any document which states that "elements called
'panData' may only be used in object extensions". There may be some XML
convention that I'm not aware of; certainly that's not mentioned in RFCs
5730 and RFC 3735.

I would be happy to give it another name, but I chose "panData" to stay
consistent with the format of poll messages in other documents. How
about <revData>?

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1301">
      <msg>Command completed successfully; ack to dequeue</msg>
    </result>
    <msgQ count="5" id="12345">
      <qDate>2016-04-04T22:01:00.0Z</qDate>
      <msg>Pending action completed successfully.</msg>
    </msgQ>
    <resData>
      <reverse:revData
        xmlns:reverse="urn:ietf:params:xml:ns:reverse-0.1">
        <reverse:reTRID reResult="1">
          <reverse:clTRID>ABC-12345</reverse:clTRID>
          <reverse:svTRID>54321-XYZ</reverse:svTRID>
        </reverse:reTRID>
        <reverse:reDate>2016-04-04T22:00:00.0Z</reverse:reDate>
      </reverse:revData>
    </resData>
    <trID>
      <clTRID>BCD-23456</clTRID>
      <svTRID>65432-WXY</svTRID>
    </trID>
  </response>
</epp>

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

That sounds like a very implementation-specific issue. None of the EPP
clients and servers that I've created would need that sort of hackery to
support this extension.

> 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

<imho>Yuck!</imho>

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

The intention was that the reverse would be atomic, so that either all
the changes in the original command are reversed, or none of them are.
I'll add something to make that explicit.

>  What if the wrong transaction is undone

This would only happen if a) the client sends the wrong transaction
identifier or b) the server processes the command incorrectly. I don't
see how this extension is uniquely at risk of either of these scenarios.
Clients can shoot themselves in the foot just as easily with the other
commands in the existing repertoire.

> and what if the transaction is not the latest one on the object?

In some situations/implementations, that wouldn't necessarily be a
problem. We (CentralNic) can trivially reverse a <renew> without also
reversing subsequent <update> commands. If the server can't reverse a
command because of a subsequent update, then it sends a 2400 response
back to the client. I will add text to that effect to the draft.

> I realize that the server transaction identifier is unique, but I wouldn’t want to make it too
> easy for inadvertent mistakes on an undo and I wouldn’t want to cause
issues with
> the state of the object.

As I mentioned above, such problems are already possible with the
current repertoire of commands.

Cheers,

G.

---

From: Gavin Brown <[email-masked]>
Date: Tue, 17 Nov 2015 18:11:26 +0000

Hi Volker,

> without the knowledge of the svTRID.

Currently, the <svTRID> is mandatory but the <clTRID> is optional. This
could be changed so that either (or both) can be specified. Thus, if the
connection dropped before the client received the response, it could
send a reverse using just its own <clTRID>.

> There is nothing to "undo" a renew, but this might be nice, if you've added to many
> years. Would not allow it if the expire gets to old by the undo.

That's a policy decision. But I would not expect any sane server
implementation to allow a <renew> to be reversed if it had exited its
grace period.

G.

---

From: "Gould, James" <[email-masked]>
Date: Tue, 17 Nov 2015 19:37:33 +0000

Gavin,

Thanks for the response.  I provide feedback to your feedback inline below.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

On Nov 17, 2015, at 1:07 PM, Gavin Brown <[email-masked]<mailto:[email-masked]>> wrote:

We currently handle this scenario offline.

Is doesn’t have anything to do with the name of the element.  You can call it panData or revData or anything else.  The main issue is the placement of the element in the response.  Per RFC 5730 it states “An OPTIONAL <resData> (response data) element that contains child elements specific to the command and associated object” and is described for an Object Extension in section 2.7.2.  The response is clearly a command-response extension and not a protocol extension.  The extension is using a protocol extension for the command and a command-response extension for the poll message.

This is not hackery, since the use of a factory makes the client or server extensible to handle any form of extension (protocol, command-response, or object).  The reason I point this out is that mixing a protocol extension with a command-response extension means that the XML namespace should be included in the <svcExtension> and the <objURI> elements of the greeting and login packets.  I also wanted to define why there can be implementation impacts in the mixing of the extensions with the same specification and XML namespace.

<imho>Yuck!</imho>

I’m not sure why use of a create to submit a reversal request is not more natural then creating a protocol extension.  The advantage of the create is that you are creating a reversal request object that can be processed synchronously or asynchronously with all of the features of a object extension (transaction identifiers and command-response extensions).  The pending action poll message can asynchronously return the pending action result or you can provide support for an info command and response for retrieving the status of the reversal request on demand.

Yes, but we’re talking about the same clients that may have caused the initial issue due to a coding error.  There would need to be some server policy on what can or should be undone, but there needs to be adequate safeguards as well unless you want to also implement a redo.

There can be reporting (financial and ICANN) that can be impacted by reversing transactions in general and potentially even more so with transactions prior to the latest transaction.

Well this extension is keying off of the server transaction identifier to execute the undue, so it is somewhat unique and must include some safeguards.

Cheers,

G.

---

From: Jothan Frakes <[email-masked]>
Date: Tue, 17 Nov 2015 23:18:21 -0800

> implementation to allow a <renew> to be reversed if it had exited its

​I dunno about sane - registry premium domains have revised the new
measurement for sane to be candid.  Especially related to premium renewal
rates (vs. everything at a flat regfee)

I am starting to see some registries make friendly amendments to their
premium renewal pricing - either accepting standard regfee as a 'deposit'
on the renewal (many registrars are still working the kinks out on premium
renewals) and then allowing the remainder amount to be paid out of band. ​

I have also heard rumor that some registries have chosen to relax their
premium renewals in order to keep two digit renewal percentages at the
anniversary of premium names, or forgiving them on a case by case basis.
An automated renewal -might- process with a premium price and need to be
rolled back, or vice-versa.

I could see the registry instead implementing undo somewhere in the mix
related to renewals in these situations.

Jothan Frakes
+1.206-355-0230 tel
+1.206-201-6881 fax
​​

On Tue, Nov 17, 2015 at 10:11 AM, Gavin Brown <[email-masked]>
wrote:

> _______________________________________________
> EppExt mailing list
> [email-masked]

---

From: Rik Ribbers <[email-masked]>
Date: Wed, 18 Nov 2015 08:49:34 +0000

> On 17 Nov 2015, at 20:37, Gould, James <[email-masked]> wrote:
> 
>>> 

From a personal perspective I agree with Gavin: Yuck!  However the question is what the goal of this draft is:

- Document the existing implementation for registration in EPP IANA registry? Then you can do whatever you like, get an expert review and leave the document as you wish

- Ask for WG-adoption and go for Standards Track; Ai, you might end up in the same situation as the keyrelay draft where there was a status quo on how to continue with the XML structure. In the end there were four people expressing their opinion on this matter and I decided to follow that advice, beside my own personal preference.

Can you tell us what your plans are for this draft? 

One other question: How does the server hello message look like with respect to this extension? 

Gr,
Rik

---

From: Gavin Brown <[email-masked]>
Date: Wed, 25 Nov 2015 15:11:41 +0000

Hi Rik,

> From a personal perspective I agree with Gavin: Yuck!  However the
> question is what the goal of this draft is:
> 
> - Document the existing implementation for registration in EPP IANA
> registry? Then you can do whatever you like, get an expert review and
> leave the document as you wish
> 
> - Ask for WG-adoption and go for Standards Track; Ai, you might end up
> in the same situation as the keyrelay draft where there was a status quo
> on how to continue with the XML structure. In the end there were four
> people expressing their opinion on this matter and I decided to follow
> that advice, beside my own personal preference.
> 

There are currently no existing implementations, and I am not especially
interested in going for WG adoption. I wrote the extension to address a
relatively common support request we get from clients (to reverse an
erroneous renewal), and submitted it to the list for feedback.

We will probably implement the extension in our server at some point
once the specification has stabilised following feedback.

> respect to this extension? 

The server would advertise the namespace of the extension in an <extURI>
element in the <svcExtension> section. It would not appear in an
<objURI> element.

G.

---

From: "Gould, James" <[email-masked]>
Date: Wed, 25 Nov 2015 16:19:30 +0000

Gavin,

As the draft is currently defined, the namespace should be in <extURI> to reflect the protocol extension of the command and be in <objURI> to reflect the object extension of the poll message.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

On Nov 25, 2015, at 10:11 AM, Gavin Brown <[email-masked]<mailto:[email-masked]>> wrote:

Hi Rik,

One other question: How does the server hello message look like with
respect to this extension?

G.