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