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

Jothan Frakes <jothan@jothan.com> Wed, 18 November 2015 07:19 UTC

Return-Path: <jothan@gmail.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 434A31AD37C for <eppext@ietfa.amsl.com>; Tue, 17 Nov 2015 23:19:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 HDCbSkDKi49P for <eppext@ietfa.amsl.com>; Tue, 17 Nov 2015 23:19:02 -0800 (PST)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 2CB1F1AD37B for <eppext@ietf.org>; Tue, 17 Nov 2015 23:19:02 -0800 (PST)
Received: by igcph11 with SMTP id ph11so95964889igc.1 for <eppext@ietf.org>; Tue, 17 Nov 2015 23:19:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=1tp2udzYr5NzBbe8kqnviaeOduIBx8xK04JPXFzk0jQ=; b=o+qesBK1ggzb8kzW3xLH1UEPseLULlqcSYxYaOOmBxBnALz7pIXzkGoIbhMg3wokzm Rp5lvq+yMzg0OKTHaZDuyuryGlVMFrh4CJji8vz7HrVlN1RfT8ZGs6fvfDOKRFoBaPeB 2FVHn2OqdRK9oDw+v/YQoReXezqAeC/AxiectJFT137lQUYi6n/gbNlWb56Qvd2MqSyN 89zcwkygRoMBNxyY6h35AXH6d+2cfsfST7I1iMnzroDsS3MlLxllju3zCa5Wyl1R1aSZ qB0LWYeeEnFbftVdCfb8sVnUpNfOMKc5eazLk3/SUOE3FeAvVfZnBB+63fafGK64qBDm KS4g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jothan-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=1tp2udzYr5NzBbe8kqnviaeOduIBx8xK04JPXFzk0jQ=; b=JEx4EH3BWU2NDGl1SkzKuXPWJTqML9vqm10K2WzVNtEv9LLyYNpDWvWnMsIhaEwmtw nUlEgdlqr9pApkjxe2MkN0+iBI6egxKUA/JgSI24kSJmnKMT/H9w9oOxq0HzpYUNSTVH UiovaT7r5Ncq8jMl2BBY6+IdNU1B8W0he+ntaGh4Zag+NCkUnFtZwfQdWGyH6yq3o/Cx TJdxJjqg/kFpPfIB/V8eH3G9NG9VD5cnWn9TpQzUkzrKyEktUJRqpNOIsRqBLG1fY2Du 3i8v9C1Kp6Oh3hPp4eG6tYnTDhoBgUPjA6RE4kwxLs8oj0rWyEJFY5jqAKOG8j1m2dlN 9C6g==
X-Received: by 10.50.137.34 with SMTP id qf2mr1789492igb.20.1447831141194; Tue, 17 Nov 2015 23:19:01 -0800 (PST)
MIME-Version: 1.0
Sender: jothan@gmail.com
Received: by 10.64.158.163 with HTTP; Tue, 17 Nov 2015 23:18:21 -0800 (PST)
In-Reply-To: <564B6DCE.4090309@centralnic.com>
References: <20151113104509.14378.51007.idtracker@ietfa.amsl.com> <5645C329.4030501@centralnic.com> <5645C677.1070108@internetx.com> <564B6DCE.4090309@centralnic.com>
From: Jothan Frakes <jothan@jothan.com>
Date: Tue, 17 Nov 2015 23:18:21 -0800
X-Google-Sender-Auth: VFUC64o56KarIeF8VjkgV3ORm4M
Message-ID: <CADe2gh6rQo8r+3E_jqiVTat-yfJj0eF7kQHAOyr3HwiQTNo8Rw@mail.gmail.com>
To: Gavin Brown <gavin.brown@centralnic.com>
Content-Type: multipart/alternative; boundary="001a11c39d50dda3340524cb7428"
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/QsrWSxYokWn0pojvcrJeYBOYQk8>
Cc: Volker Janzen Notify <volker.janzen-notify@internetx.com>, "eppext@ietf.org" <eppext@ietf.org>
Subject: Re: [eppext] Fwd: 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: Wed, 18 Nov 2015 07:19:04 -0000

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


​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 <gavin.brown@centralnic.com>
wrote:

> Hi Volker,
>
> >> In order to reverse a command, the client need only record the
> >> <svTRID> returned by the server in its response to the command.
> >
> > 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.
>
> 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.
>
> --
> 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 mailing list
> EppExt@ietf.org
> https://www.ietf.org/mailman/listinfo/eppext
>
>