Re: [ire] XML rgpStatus definition

Patrick Mevzek <Patrick.Mevzek@afnic.fr> Thu, 22 October 2015 14:30 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 1A54E1B37D6 for <ire@ietfa.amsl.com>; Thu, 22 Oct 2015 07:30:54 -0700 (PDT)
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 RCObulpGx212 for <ire@ietfa.amsl.com>; Thu, 22 Oct 2015 07:30:53 -0700 (PDT)
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 361311B33A3 for <ire@ietf.org>; Thu, 22 Oct 2015 07:30:53 -0700 (PDT)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id A04672803E1; Thu, 22 Oct 2015 16:30:51 +0200 (CEST)
Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 9B26A28037B; Thu, 22 Oct 2015 16:30:51 +0200 (CEST)
Received: from citrine.tech.ipv6.nic.fr (citrine.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:96]) by relay2.nic.fr (Postfix) with ESMTP id 98E9EB38052; Thu, 22 Oct 2015 16:30:21 +0200 (CEST)
Message-ID: <1445524221.25571.33.camel@afnic.fr>
From: Patrick Mevzek <Patrick.Mevzek@afnic.fr>
To: "Gould, James" <JGould@verisign.com>
Date: Thu, 22 Oct 2015 16:30:21 +0200
In-Reply-To: <B3555456-E53A-4855-A4D3-CF4D69BA8728@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>
Organization: AFNIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.16.5 (3.16.5-3.fc22)
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ire/vvf1t70oq7_8Ltu17Qx5xXR4kFY>
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: Thu, 22 Oct 2015 14:30:54 -0000

Le jeudi 22 octobre 2015 à 14:21 +0000, Gould, James a écrit :
> So what do you think about the rgp endDate in the escrow data?
> > It seems to me it would be useful…
> > Otherwise you need to do some hack calculations based on upDate and
> > the
> > registry policies about grace periods durations (which are not set
> > in
> > stone by the RFC3915 nor ICANN).
> > 
> The grace period end date is calculated based on the business logic
> and not stored in the registry database, so it is not something that
> would be included in the escrow data.  

Registry policy/internal implementation detail I think: I know at least
one registry operator where grace period end dates are stored in the
database (to speed up various other checks).

The calculation needs to be done only once (at start of the grace
period), it can make sense to keep the result and not do it many times
after.

Also, if registry operator changes (the purpose of escrowing stuff),
how should the new operator know all the grace period end dates,
especially if it does not have access to all the business logic details
of its predecessor?
Or you mean that the new registry operator business logic would kick it
at that time, but then you have the problem of knowing when the grace
period started, for which you may use the upDate of the domain
probably.

-- 
Patrick Mevzek