Re: [eppext] New Version Notification for draft-brown-epp-reverse-00.txt
Gavin Brown <gavin.brown@centralnic.com> Tue, 17 November 2015 18:08 UTC
Return-Path: <gavin.brown@centralnic.com>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0C781B303A for <eppext@ietfa.amsl.com>; Tue, 17 Nov 2015 10:08:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.214
X-Spam-Level:
X-Spam-Status: No, score=0.214 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Di6Nz59Hjp5c for <eppext@ietfa.amsl.com>; Tue, 17 Nov 2015 10:08:13 -0800 (PST)
Received: from smtp.centralnic.com (smtp.centralnic.com [212.18.250.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE2CB1B303E for <eppext@ietf.org>; Tue, 17 Nov 2015 10:07:13 -0800 (PST)
Received: from [192.168.1.143] (unknown [31.74.104.127]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 8FBC3E1393; Tue, 17 Nov 2015 18:07:10 +0000 (UTC)
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>
X-Enigmail-Draft-Status: N1110
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
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Nov 2015 18:08:16 -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. -- 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.
- [eppext] Fwd: New Version Notification for draft-… Gavin Brown
- Re: [eppext] Fwd: New Version Notification for dr… Volker Janzen Notify
- Re: [eppext] New Version Notification for draft-b… Gould, James
- Re: [eppext] New Version Notification for draft-b… Gavin Brown
- Re: [eppext] Fwd: New Version Notification for dr… Gavin Brown
- Re: [eppext] New Version Notification for draft-b… Gould, James
- Re: [eppext] Fwd: New Version Notification for dr… Jothan Frakes
- Re: [eppext] New Version Notification for draft-b… Rik Ribbers
- Re: [eppext] New Version Notification for draft-b… Gavin Brown
- Re: [eppext] New Version Notification for draft-b… Gould, James