Re: [ire] XML rgpStatus definition

"Gould, James" <JGould@verisign.com> Thu, 22 October 2015 14:44 UTC

Return-Path: <JGould@verisign.com>
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 164E61B3898 for <ire@ietfa.amsl.com>; Thu, 22 Oct 2015 07:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 Ke8eW8B9Kg8t for <ire@ietfa.amsl.com>; Thu, 22 Oct 2015 07:44:15 -0700 (PDT)
Received: from mail-qg0-f98.google.com (mail-qg0-f98.google.com [209.85.192.98]) (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 CBC861B3864 for <ire@ietf.org>; Thu, 22 Oct 2015 07:44:14 -0700 (PDT)
Received: by qgad10 with SMTP id d10so4000426qga.3 for <ire@ietf.org>; Thu, 22 Oct 2015 07:44:14 -0700 (PDT)
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=6H+zWmI0UTNp71QYhK2nfbnRPWit6a7xYnDp45oe34o=; b=K5J6A4titHR5cmEVNcvBHcugA+H3slVIJOnhJgL5dk2wb+tKRg5fft+QmeVHw52f6K y+O7JN31OJSatC+4pW+gn4Vy7s810Gz4oejmXsaEVCoBAyAS76cSRND3Qzcu5/gI9lJh FRrW963k2tmwZoSfWZfl8BZDL8UqRwDomRC6JsVyTzYz0An5vC39hy/bthUss6ZbbWbo MAgh59dkX4dOxLy6l/lHM8NYlJH6Ve8a4/hGoHVmQ8MHOWUByvDlnm4dmrVaBCOnxBJS 8uLJYcUiAb6S0CCdFAxdAcmHA4WvYU40+Mq/SpGLXYImsg3W1vBDqITerRUSqUcHiYYE FcdA==
X-Gm-Message-State: ALoCoQkPEVijpzQ3S1QYeCxNBb1DMCrl+1Zh9kWFO3uoAvjyKwQNYnV11H2eBECwpXHwTyInokFrVrtfG5XNzEKBI19iWK/ceA==
X-Received: by 10.140.95.53 with SMTP id h50mr18993670qge.8.1445525053808; Thu, 22 Oct 2015 07:44:13 -0700 (PDT)
Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id f92sm1899502qkf.8.2015.10.22.07.44.13 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 22 Oct 2015 07:44:13 -0700 (PDT)
X-Relaying-Domain: verisign.com
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t9MEiDut026442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Oct 2015 10:44:13 -0400
Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 22 Oct 2015 10:44:13 -0400
From: "Gould, James" <JGould@verisign.com>
To: Patrick Mevzek <Patrick.Mevzek@afnic.fr>
Thread-Topic: [ire] XML rgpStatus definition
Thread-Index: AQHQktoIsBLfNykcPU6a1tKLGGvXH52E04EAgAAC5ICA8+5oAIAAAmcAgAACgoCAAAPfAA==
Date: Thu, 22 Oct 2015 14:44:12 +0000
Message-ID: <A81FAEEF-D0DB-4624-A43C-071548C1B843@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>
In-Reply-To: <1445524221.25571.33.camel@afnic.fr>
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_A81FAEEFD0DB4624A43C071548C1B843verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ire/-fwiemB1Sndat9cSkAx71BGg8ho>
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:44:17 -0000

Patrick,

My feedback is 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 Oct 22, 2015, at 10:30 AM, Patrick Mevzek <Patrick.Mevzek@afnic.fr<mailto:Patrick.Mevzek@afnic.fr>> wrote:

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

That is an implementation decision for that registry, but that is not the case for us.


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.


We calculate the applicable grace periods dynamically based on the various grace period rules that apply.  This is not static data.

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.


Will the gaining registry operator really provide grace period credits?  It would be interesting to hear from the EBERO providers what they will or should support related to grace periods and credits.  Grace periods is not persisted in our registries and is not applicable for escrow.

--
Patrick Mevzek