Re: [eppext] New Version Notification for draft-brown-epp-reverse-00.txt
"Gould, James" <JGould@verisign.com> Tue, 17 November 2015 19:37 UTC
Return-Path: <JGould@verisign.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 B5A801A7D84 for <eppext@ietfa.amsl.com>; Tue, 17 Nov 2015 11:37:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qb1KnEGnDGA for <eppext@ietfa.amsl.com>; Tue, 17 Nov 2015 11:37:35 -0800 (PST)
Received: from mail-qg0-x261.google.com (mail-qg0-x261.google.com [IPv6:2607:f8b0:400d:c04::261]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915131A7D83 for <eppext@ietf.org>; Tue, 17 Nov 2015 11:37:35 -0800 (PST)
Received: by qgae107 with SMTP id e107so1631920qga.1 for <eppext@ietf.org>; Tue, 17 Nov 2015 11:37:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign_com.20150623.gappssmtp.com; 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=jm/IZa/RBXOOq4eH+BiQ0PwDj3yfwW6xJ9fG/nz9zjQ=; b=XvZLMk9ci3oAbV7jhXJWZp9/Xo0dc6wtNOJ82sWt9V9y4iuDR9boC9RzEkAHwONpez l2b/pB27vxZKdiOEun++pDRU9MzvC/81yEg7SOpdjOsw5MuQ8psTwaDpIkxClLIBxgoD /04tGJGXj+TUMSRHnb1muEmbEFhVkiBJVS3c/S/j6usENxLeqSnvYaQmsPX02QUVXCK+ 2iEAsuLoBm1uBq5AqDO2+K8+evsJO1aJEsTPiFkiGEq854YXHuC0cnXRks0HGH27Dbrt EbMAMylItCQDTaeYu4U2OMufkkXBOkGMpyjJmKL4NyIOF50YSs2dtRafm26+0iDRsMTr EI8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=jm/IZa/RBXOOq4eH+BiQ0PwDj3yfwW6xJ9fG/nz9zjQ=; b=HTQdj4F5q2IysK3TMmaGL7s4oXAeThkLfB9G3nnBVToYf82sOR5DZq9ORjJw+KBb1Y m3HOeZJmezAzXwH2syHf0yExcxkvgoZgaUQI4VkIUkYRgpizG1uOb6gf7uyjYzT5RnVd T899/A5vB4Zys7t2S+U1w675vNWPKb1LYbEHUnFJ8gAZ4ClgoDSOKfmjWnKYsLSKkqJA uCNP0b39sgLaamfviGp1k0P1oD3GK7BjasNO4eqmdPKiig79zkr2fvHhrReZftYIhoed yfz1393jzYcDWrcb5W2Q84DlKhvgFJjS4lpxPlfmJFTMz7MbBJ9BeAuvym9YScP93Ynj sOFw==
X-Gm-Message-State: ALoCoQnmetHX1RB3GjfsvphvqdTkE6dEJVKOFXYZoqUF2LJdsoUsXPtLAJVVhPGBqJdG1wWBQpQRjlOVSAf7VZCgXBcJ0Ic7yw==
X-Received: by 10.55.22.13 with SMTP id g13mr44229308qkh.8.1447789054416; Tue, 17 Nov 2015 11:37:34 -0800 (PST)
Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id d18sm3243242qka.6.2015.11.17.11.37.34 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 17 Nov 2015 11:37:34 -0800 (PST)
X-Relaying-Domain: verisign.com
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id tAHJbXT0021515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Nov 2015 14:37:33 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 17 Nov 2015 14:37:33 -0500
From: "Gould, James" <JGould@verisign.com>
To: Gavin Brown <gavin.brown@centralnic.com>
Thread-Topic: [eppext] New Version Notification for draft-brown-epp-reverse-00.txt
Thread-Index: AQHRIWLKM0ThfG965EqhXA5DHd60JZ6g79qA
Date: Tue, 17 Nov 2015 19:37:33 +0000
Message-ID: <863B3B96-AC96-4D54-9550-B075E548B08B@verisign.com>
References: <20151113104509.14378.51007.idtracker@ietfa.amsl.com> <5645C329.4030501@centralnic.com> <E954898F-ACE4-4978-A3B8-19CB50466F52@verisign.com> <564B6CCA.1000704@centralnic.com>
In-Reply-To: <564B6CCA.1000704@centralnic.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: multipart/related; boundary="_004_863B3B96AC964D549550B075E548B08Bverisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/-Ubyo31bD4vPxPiXN-Asgn2yeHg>
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 19:37:39 -0000
Gavin, Thanks for the response. I provide feedback to your feedback inline below. — JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> On Nov 17, 2015, at 1:07 PM, Gavin Brown <gavin.brown@centralnic.com<mailto:gavin.brown@centralnic.com>> wrote: 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. We currently handle this scenario offline. 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> 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. 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. 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. 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’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. 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. 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. 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. 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. 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. 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. -- 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