To: "Gould, James" <JGould@verisign.com>
References: <20151113104509.14378.51007.idtracker@ietfa.amsl.com>
 <5645C329.4030501@centralnic.com>
 <E954898F-ACE4-4978-A3B8-19CB50466F52@verisign.com>
From: Gavin Brown <gavin.brown@centralnic.com>
Organization: CentralNic
Message-ID: <564B6CCA.1000704@centralnic.com>
Date: Tue, 17 Nov 2015 18:07:06 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <E954898F-ACE4-4978-A3B8-19CB50466F52@verisign.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="JMeI9U541StirqaCgtu1bQG8MIxsqfnUM"
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/8lqedO4J1oa7Ry-25Td-kRNb9LQ>
Cc: Jothan Frakes <jothan@jothan.com>, "eppext@ietf.org" <eppext@ietf.org>
Subject: Re: [eppext] New Version Notification for
 draft-brown-epp-reverse-00.txt
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--JMeI9U541StirqaCgtu1bQG8MIxsqfnUM
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Jim, thanks for the feedback.

> I have not heard of the need for such a undue or reverse feature, but
> I=E2=80=99ll check to see whether this feature is useful with our produ=
ct team. =20

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=3D"1.0" encoding=3D"utf-8" standalone=3D"no"?>
<epp xmlns=3D"urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code=3D"1301">
      <msg>Command completed successfully; ack to dequeue</msg>
    </result>
    <msgQ count=3D"5" id=3D"12345">
      <qDate>2016-04-04T22:01:00.0Z</qDate>
      <msg>Pending action completed successfully.</msg>
    </msgQ>
    <resData>
      <reverse:revData
        xmlns:reverse=3D"urn:ietf:params:xml:ns:reverse-0.1">
        <reverse:reTRID reResult=3D"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 needin=
g 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 an=
d
> 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 would=
n=E2=80=99t want to make it too
> easy for inadvertent mistakes on an undo and I wouldn=E2=80=99t 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.

--=20
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.


--JMeI9U541StirqaCgtu1bQG8MIxsqfnUM
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJWS2zLAAoJEIyjpGZF+8MZpsAP/iOaY+zvGXPx5bxhsYgoy+WX
jhAtjuc6jTOXNNWExHPCnwgMWOC8ba8Nxp6ldgGq5vGJ4ctmITnbpa4gcSPAvU7V
ZEGisI/DhzV51JCkJ5W5d6kkIxdRBGbTJy+XSeIPERwGWtIFEAH/hGcCdm/ox57l
ez/09gynprsGf7lFMXkiwup+eeV52y9coE8xwWbr9zvUJQiJyEeGTgimdj+ZBBMb
cPgJHQ3wqAwTtIuRN42d1TjxXMLxrgvS2cUID96dFgKIsxl6WBHkHGg3MYp4bgxZ
Up5McwnrqTq6O7GDOI+ehnPJ1BFg7OJFFGr9whm2t32ab5ii4FYaJHpLzFTiZlln
ymzPp7sQ3qut6VmcZeA4AL8Pme8f/MXFqu3hPiBpfSGlw1rgfS2wuX6RR+5mOR9w
t3CqYRFUUjwaUGM5/844l72x+Ta1Sx+CWm/1+mckekr/Z5SVgv1es107KRjBD5QI
nN94RrBcl68uFZhrNBJtQ8NHQTXWetI5q61H23NZPMzJ//XShN6FOE5GfTQcsPDb
187RlwBYr4wF4IpHhBjXIeSM2lyj32vwrjDaHxoQk+3nBhBj156eMd6mDr6VqW3N
Mjsfna1dSCnjspBP9gFYj84SzyrYZwXGzM6tj4+9HCE0IRoQijPafNBBdCsfV9UJ
hQADXeS1UTRc46tFOovE
=rMER
-----END PGP SIGNATURE-----

--JMeI9U541StirqaCgtu1bQG8MIxsqfnUM--