Re: [ire] XML rgpStatus definition

Patrick Mevzek <Patrick.Mevzek@afnic.fr> Tue, 03 November 2015 02:29 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 4C6131ACDE7 for <ire@ietfa.amsl.com>; Mon, 2 Nov 2015 18:29:00 -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 tB3h_7dI_zwl for <ire@ietfa.amsl.com>; Mon, 2 Nov 2015 18:28:59 -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 6C8A61A87ED for <ire@ietf.org>; Mon, 2 Nov 2015 18:28:59 -0800 (PST)
Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 151A628019F; Tue, 3 Nov 2015 03:28:58 +0100 (CET)
Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx4.nic.fr (Postfix) with ESMTP id 0F905280124; Tue, 3 Nov 2015 03:28:58 +0100 (CET)
Received: from [IPv6:::1] (citrine.tech.ipv6.nic.fr [IPv6:2001:67c:1348:7::86:96]) by relay2.nic.fr (Postfix) with ESMTP id BDD58B38039; Tue, 3 Nov 2015 03:28:26 +0100 (CET)
Message-ID: <1446517705.29808.24.camel@citrine-mobile>
From: Patrick Mevzek <Patrick.Mevzek@afnic.fr>
To: Christopher Browne <cbbrowne@afilias.info>
Date: Tue, 03 Nov 2015 11:28:25 +0900
In-Reply-To: <CANfbgbZpKXA0+RjhRGtEj_w7xJwNkZWPQLQWJ67CSNLFGB3Qcg@mail.gmail.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> <CANfbgbZpKXA0+RjhRGtEj_w7xJwNkZWPQLQWJ67CSNLFGB3Qcg@mail.gmail.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/67PR3cx-Qb-pH1Mt__JnEpywqVY>
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:29:00 -0000

Le jeudi 22 octobre 2015 à 17:03 -0400, Christopher Browne a écrit :

> I'm uncomfortable with basing the inclusion/exclusion of grace period
> data based on whether or not a particular registry implementation
> stores or computes it.  That conflates implementation with policy.

This is not what I've written or maybe I was not clear.
I was just saying that if the XML/CSV schema allows (without making it
mandatory) to convey grace periods information, then it is better,
because people are then free to choose to use that option or not.
If the option is not available, then there is no choice (yeah, obvious).

But at the end of the day, it is not a big deal.

> On the other hand, when IRE captures neither transactions nor amounts,
> it seems entirely surprising for it to indicate grace periods.

This is orthogonal for me. Imagine a registry where domain names are
free. You may still need autoRenew periods and deletion grace periods…

> I'd be surprised for an EBERO that is temporarily providing services
> to be interested in getting into offering grace period-based refunds,
> and I'm not sure that fits with the arrangements with ICANN.

This is policy considerations. I was just saying that if the technical
protocol allows this option (one option among others) then it is better.
Other layers would decide if this technical option is put to use or not.

>  Typical grace periods would likely have long expired by the time a
> transition would take place to a more permanent successor operator.

Like the 45 days autoRenew period ?
You think EBERO switches would take more than 45 days ?

-- 
Patrick Mevzek