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

"Gould, James" <> Fri, 13 November 2015 13:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7EFA61A8884 for <>; Fri, 13 Nov 2015 05:59:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BEp5uEwNHJ7e for <>; Fri, 13 Nov 2015 05:59:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::263]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A5411A887D for <>; Fri, 13 Nov 2015 05:59:32 -0800 (PST)
Received: by oie188 with SMTP id 188so6393202oie.0 for <>; Fri, 13 Nov 2015 05:59:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:mime-version; bh=/JSDxcfBAtaxjBBftlaibOggd6gf/iVRUa5neFMHs4c=; b=0XQK6A6S6IHhS4gxX4zCzFkxR/PkIjrTwC5j0soFUDcwy+7ct8ns7eYLlNywWahV03 P4+/09hE8piuZbfSdGFeISdJlCIiBPsSWzyollwU+2UMbwrPU3aaPADlslnK2BdwCR4F WlFZ6Cm4K3KcThHgfcMoDctvPMcUGZQK5MWwlOYiQc5PjnsDCW1zPde5jfqH/+kKILUQ E7GfVjxVOXOdWcnfnm63GKAHvYpqJP7Ny2afBLc78cIlmXhp7UOSytrOHdEVvaWsANS/ 9vwxa2JuQK+vknDjlXlNP+Ygkf2ZX1R4lLtwc/eVNxJu75qGlvMETmy29IinrXpznpZc k98Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=/JSDxcfBAtaxjBBftlaibOggd6gf/iVRUa5neFMHs4c=; b=NA0TPhmjqfIEsbHubsp+ZouXgk7WRJ85xnegMFvGIu8+qymmexy5ZZEAZfFWJybpUZ 6q3eYONeEX/2pkl/s/7ORAVtuEfyUDSjGVweHqo+pjXkyC3dk0nqlGYcfYAt8to7+rXY W/8p176/3AngKteubQ/3xZ9uF2ONp0YNn87cavpgOP6dVdwcfDSH7nnef4OVwoIbSUL9 VFkg9xAA6wnVpIotO5XKZch+0At3dq80nltp3jYR9gFJPMj1A2TMYY1n45ZetqlIPPw7 AFlx2+7XaPln4cwK7CKidqKYDGUX46DLELH08K9C4Tu3XCTL1GMXIQoFpB1oqEQpdVsd 3ycA==
X-Gm-Message-State: ALoCoQm+XW6oDcTSS6Fe/obeXFE7otVJiWoBws+SHuGIr20oXBsywoYHq9scv1W5qT4gPjBMIejP0xcNqGub1uZ2VvOCLomhgw==
X-Received: by with SMTP id b136mr22052128qka.100.1447423171359; Fri, 13 Nov 2015 05:59:31 -0800 (PST)
Received: from ( []) by with ESMTPS id w196sm1570480qka.5.2015. (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 13 Nov 2015 05:59:31 -0800 (PST)
Received: from (brn1wnexcas02 []) by (8.13.8/8.13.8) with ESMTP id tADDxUnc000624 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 08:59:30 -0500
Received: from ([::1]) by ([::1]) with mapi id 14.03.0174.001; Fri, 13 Nov 2015 08:59:30 -0500
From: "Gould, James" <>
To: Gavin Brown <>
Thread-Topic: [eppext] New Version Notification for draft-brown-epp-reverse-00.txt
Thread-Index: AQHRHhuDlapyknW550i6lSTVsWvnfg==
Date: Fri, 13 Nov 2015 13:59:30 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/related; boundary="_004_E954898FACE44978A3B819CB50466F52verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <>
Cc: Jothan Frakes <>, "" <>
Subject: Re: [eppext] New Version Notification for draft-brown-epp-reverse-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Nov 2015 13:59:35 -0000


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.





James Gould
Distinguished Engineer

12061 Bluemont Way
Reston, VA 20190<>

On Nov 13, 2015, at 6:02 AM, Gavin Brown <<>> 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!



Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
<New Version Notification for draft-brown-epp-reverse-00_txt.eml>_______________________________________________
EppExt mailing list