Re: [ire] XML rgpStatus definition
Patrick Mevzek <Patrick.Mevzek@afnic.fr> Tue, 03 November 2015 02:24 UTC
Return-Path: <Patrick.Mevzek@afnic.fr>
X-Original-To: ire@ietfa.amsl.com
Delivered-To: ire@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC83D1ACDCB for <ire@ietfa.amsl.com>; Mon, 2 Nov 2015 18:24:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35] 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 D9obAb-l8f4U for <ire@ietfa.amsl.com>; Mon, 2 Nov 2015 18:24:13 -0800 (PST)
Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 1E8BC1ACDCE for <ire@ietf.org>; Mon, 2 Nov 2015 18:24:13 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 418A628019F; Tue, 3 Nov 2015 03:24:11 +0100 (CET)
Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id 3C796280124; Tue, 3 Nov 2015 03:24:11 +0100 (CET)
Received: from [IPv6:::1] (citrine.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:96]) by relay1.nic.fr (Postfix) with ESMTP id 399EE4C007F; Tue, 3 Nov 2015 03:23:39 +0100 (CET)
Message-ID: <1446517419.29808.19.camel@citrine-mobile>
From: Patrick Mevzek <Patrick.Mevzek@afnic.fr>
To: "Gould, James" <JGould@verisign.com>
Date: Tue, 03 Nov 2015 11:23:39 +0900
In-Reply-To: <323E513A-20A2-4478-AECF-2744FC5ECA01@verisign.com>
References: <CAC1BbcQSBYa1JE4C2tM5+WqmFOMVSMfTk-ovYWcW_=PLQa1MiQ@mail.gmail.com> <555C4C9A.3080403@knipp.de> <CAC1BbcRjrsHK0gf3sQO_xs0C8JM+4Ftwd2=J=F8-hC09ocZbCQ@mail.gmail.com> <1445523166.25571.26.camel@afnic.fr> <B3555456-E53A-4855-A4D3-CF4D69BA8728@verisign.com> <1445524221.25571.33.camel@afnic.fr> <A81FAEEF-D0DB-4624-A43C-071548C1B843@verisign.com> <1445525362.25571.44.camel@afnic.fr> <323E513A-20A2-4478-AECF-2744FC5ECA01@verisign.com>
Organization: AFNIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.8.5-2+b1
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ire/mUD7dYTYkXcQ7eHvn37spjVGASw>
Cc: "ire@ietf.org" <ire@ietf.org>
Subject: Re: [ire] XML rgpStatus definition
X-BeenThere: ire@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Internet Registration Escrow discussion list." <ire.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ire>, <mailto:ire-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ire/>
List-Post: <mailto:ire@ietf.org>
List-Help: <mailto:ire-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ire>, <mailto:ire-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2015 02:24:14 -0000
Le jeudi 22 octobre 2015 à 15:30 +0000, Gould, James a écrit : > Patrick, > > > Grace periods typically don’t apply across registrar transfers, so > why would they apply across registry transfers? Because for me the whole purpose of an EBERO is to keep the zone running, without impacts for registrants. Also a registrar transfer is something that normally happens under the instructions of the registrant, while a switch to an EBERO may remain (and should even remain) completely invisible to end-users. Imagine a domain that was auto-renewed, and then 5 days later the zone is transfered to an EBERO. Imagine the end-user did not want to renew it. In normal cases the registrar would be able to undo the transaction because it is in autoRenew grace period. If these periods are removed during the switch to the EBERO, it means all registrars will be billed for all domains auto-renewed up to 45 days (typically) before the switch… even if the end-users did not want to keep the domains. So potential huge costs for registrars. Or do you think that in the urgency of the EBERO switch each registrar will do its housekeeping before leaving the old registry? Same in another case: involuntarily deletion of domain, then switch to EBERO. No way to restore the domain name then ? I'm not saying that things must run like that. I'm saying that it may make sense in some business model to run like that, and if the "protocol/infrastructure" permits that (and leave the operators to decide policy-wise if they want to do it or not) it is better. > Would the EBERO providers be willing to provide grace period credits > for transactions they never received funds for? Going down the path > of trying to get the grace periods to transfer will lead to a large > list of issues. My recommendation is for the grace periods to only be > applicable within the life of an individual registry, meaning they do > not transfer upon failure to an EBERO provider or from an EBERO > provider back to a registry. I agree with your train of thoughts. I am just presenting another path that is not in contradiction to yours. -- Patrick Mevzek
- [ire] XML rgpStatus definition Bernhard Reutner-Fischer
- Re: [ire] XML rgpStatus definition Michael Bauland
- Re: [ire] XML rgpStatus definition Bernhard Reutner-Fischer
- Re: [ire] XML rgpStatus definition Patrick Mevzek
- Re: [ire] XML rgpStatus definition Gould, James
- Re: [ire] XML rgpStatus definition Patrick Mevzek
- Re: [ire] XML rgpStatus definition Gould, James
- Re: [ire] XML rgpStatus definition Patrick Mevzek
- Re: [ire] XML rgpStatus definition Gould, James
- Re: [ire] XML rgpStatus definition Christopher Browne
- Re: [ire] XML rgpStatus definition Patrick Mevzek
- Re: [ire] XML rgpStatus definition Patrick Mevzek