Re: [ire] XML rgpStatus definition

Christopher Browne <cbbrowne@afilias.info> Thu, 22 October 2015 21:03 UTC

Return-Path: <cbbrowne@afilias.info>
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 093D21B4152 for <ire@ietfa.amsl.com>; Thu, 22 Oct 2015 14:03:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.588
X-Spam-Level:
X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qookqrUWuC91 for <ire@ietfa.amsl.com>; Thu, 22 Oct 2015 14:03:50 -0700 (PDT)
Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) (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 8AEFE1B414D for <ire@ietf.org>; Thu, 22 Oct 2015 14:03:50 -0700 (PDT)
Received: from maia.afilias-int.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from <cbbrowne@afilias.info>) id 1ZpN1Z-0003tE-4b for ire@ietf.org; Thu, 22 Oct 2015 21:03:49 +0000
Received: from mail-oi0-f54.google.com ([209.85.218.54]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from <cbbrowne@afilias.info>) id 1ZpN1Z-0005xK-4I for ire@ietf.org; Thu, 22 Oct 2015 21:03:49 +0000
Received: by oifu63 with SMTP id u63so12298837oif.2 for <ire@ietf.org>; Thu, 22 Oct 2015 14:03:44 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=R0PFXp+tUSuIM4W5vIA2NDFyf2thtPM8docaUvp6yJM=; b=I8OsftFuCHF63a1Vzz2tLAGo05zq9wlst8nDuJO3XNjZkij7aTree7BP9IWSkdaZii iRAj44LFuI2ejb9ItAUhB7AVlKohnyaDgaDbKHOsOUzgkEJtSO0UYR5KLbNYUuoEE9Uy 78bjoOaN03fttmcdCYO8gcqipGOcF5a/vMZFTsigsacPT/k0Pc1RdVyqijfIdnbDWuRv Wc+3HTAJOF55t4kIhk6R31ZkfzdUe6e4QtmzCyW+YpYjXp1/t4Krn0/IJgIAHKbY8U6e ZolNtoFwx7DhUJoO+cuneCQMaUf262MumE5+m9HJNbQggOapHyxkeUcvmMCvSfWw67CY g0TA==
X-Gm-Message-State: ALoCoQmNmxXf1Fjvn0iY/QQ/AfCEwbcOmTNXz9XAdRmam3UhTWfc4ZrQfK9WNu7loAluxwsnJ2a+nGYaLKw1rdP9o9SwP51IRLf9W398Zlrxep337MV4VeBIJafc2f6QNNEZlCFJIdNm
X-Received: by 10.202.180.193 with SMTP id d184mr11058835oif.4.1445547823989; Thu, 22 Oct 2015 14:03:43 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.202.180.193 with SMTP id d184mr11058830oif.4.1445547823871; Thu, 22 Oct 2015 14:03:43 -0700 (PDT)
Received: by 10.202.198.138 with HTTP; Thu, 22 Oct 2015 14:03:43 -0700 (PDT)
In-Reply-To: <1445525362.25571.44.camel@afnic.fr>
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>
Date: Thu, 22 Oct 2015 17:03:43 -0400
Message-ID: <CANfbgbZpKXA0+RjhRGtEj_w7xJwNkZWPQLQWJ67CSNLFGB3Qcg@mail.gmail.com>
From: Christopher Browne <cbbrowne@afilias.info>
To: Patrick Mevzek <Patrick.Mevzek@afnic.fr>
Content-Type: multipart/alternative; boundary="001a113ce0088c5ebc0522b7d454"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ire/vTmnOKI1euv7XaChgzOJya9eh74>
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 21:03:52 -0000

On Thu, Oct 22, 2015 at 10:49 AM, Patrick Mevzek <Patrick.Mevzek@afnic.fr>
wrote:

> Le jeudi 22 octobre 2015 à 14:44 +0000, Gould, James a écrit :
> > 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.
>
> I agree with you that it (storing or recomputing) is a local decision
> by each registry.
> We may overthink the problem right now because indeed it depends on
> what the EBERO will do for domains concerned by grace periods.
> And that case has not been seen yet AFAIK.
>
> However, if there is no dates in the escrow at all, it makes it
> impossible or very difficult for EBEROs to apply refunds (if they want
> to do it of course), while if it is optionally in the escrow (and up to
> the registry generating the escrow to provide it or now), then EBEROs
> who want to do it can do it (and the others would not care about this
> piece of data).
>

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.

On the other hand, when IRE captures neither transactions nor amounts, it
seems entirely surprising for it to indicate 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.   Typical grace periods
would likely have long expired by the time a transition would take place to
a more permanent successor operator.