IETF Logo Mail Archive

Re: [ire] XML rgpStatus definition

"Gould, James" <JGould@verisign.com> Thu, 22 October 2015 15:30 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 862101A8792 for <ire@ietfa.amsl.com>; Thu, 22 Oct 2015 08:30:42 -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 Ng1-VywVmL5P for <ire@ietfa.amsl.com>; Thu, 22 Oct 2015 08:30:37 -0700 (PDT)
Received: from mail-oi0-f97.google.com (mail-oi0-f97.google.com [209.85.218.97]) (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 6B4551B38CA for <ire@ietf.org>; Thu, 22 Oct 2015 08:30:37 -0700 (PDT)
Received: by oies6 with SMTP id s6so6355982oie.3 for <ire@ietf.org>; Thu, 22 Oct 2015 08:30:36 -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=3Fur+JF/nAQz6bWgY/n42OpQxVg7CzA0pbXtFbowzQU=; b=IopZE8UDml/ycHZ8mprguOm7zhrOhQsAkpkseDFtXYRrGV4sXcJ8OI6BjSwWZh5kMu +u8vRLHeTCu7gMMrlo/Evu8aw3fZEJPVQiWKH/nj9JoIae9M1rDWEhT8XRfQllVgWRKQ wsjbF20JlfvNEfYMbsTh/ejvP3NhJj+t1SOmDve4mVwLiGVYc/FuhoTUyLj6dSKrfNOu 3Xp/DJv/Xj2TKX6LNHV4uC1e2JxRaYiqfGvoXDOMsZ/qLK6UDtRcM4nExn2wzq3ahwlO FYHo9VQZThgpw806DKdBhY9usxnomNqbKxIM350lUSitmV71Yk4chZaweE2/YlCuSEez Su5w==
X-Gm-Message-State: ALoCoQnTWe+kwBjjtK15kXO0J8nMG9yHdnNv0JFCe46okcbHmdwxaLxpLASxIASy/Jv/HJcejkLLd32ALDkmwdKNOwui9sKGbw==
X-Received: by 10.140.151.13 with SMTP id 13mr19672516qhx.41.1445527836614; Thu, 22 Oct 2015 08:30:36 -0700 (PDT)
Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id q11sm1924292qkl.6.2015.10.22.08.30.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 22 Oct 2015 08:30:36 -0700 (PDT)
X-Relaying-Domain: verisign.com
Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id t9MFUY8n032240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Oct 2015 11:30:36 -0400
Received: from BRN1WNEXMBX02.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 22 Oct 2015 11:30:34 -0400
From: "Gould, James" <JGould@verisign.com>
To: Patrick Mevzek <Patrick.Mevzek@afnic.fr>
Thread-Topic: [ire] XML rgpStatus definition
Thread-Index: AQHQktoIsBLfNykcPU6a1tKLGGvXH52E04EAgAAC5ICA8+5oAIAAAmcAgAACgoCAAAPfAIAAAXEAgAALgwA=
Date: Thu, 22 Oct 2015 15:30:34 +0000
Message-ID: <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>
In-Reply-To: <1445525362.25571.44.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_323E513A20A24478AECF2744FC5ECA01verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ire/QlNcknx1iW3lZTD9mviucZJnRSw>
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 15:30:42 -0000

Patrick,

Grace periods typically don’t apply across registrar transfers, so why would they apply across registry transfers?  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.


—


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:49 AM, Patrick Mevzek <Patrick.Mevzek@afnic.fr<mailto: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).


--
Patrick Mevzek

v2.23.0 | Report a Bug | By Email