Re: [ire] RGP status data

James Mitchell <james.mitchell@ausregistry.com.au> Wed, 16 January 2013 23:57 UTC

Return-Path: <james.mitchell@ausregistry.com.au>
X-Original-To: ire@ietfa.amsl.com
Delivered-To: ire@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0944521F874C for <ire@ietfa.amsl.com>; Wed, 16 Jan 2013 15:57:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.895
X-Spam-Level:
X-Spam-Status: No, score=-3.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk1z0soUdP7J for <ire@ietfa.amsl.com>; Wed, 16 Jan 2013 15:57:16 -0800 (PST)
Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id D5EC221F8746 for <ire@ietf.org>; Wed, 16 Jan 2013 15:57:15 -0800 (PST)
Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 17 Jan 2013 10:57:11 +1100
Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Thu, 17 Jan 2013 10:56:15 +1100
From: James Mitchell <james.mitchell@ausregistry.com.au>
To: Christopher Browne <cbbrowne@afilias.info>, "ire@ietf.org" <ire@ietf.org>
Date: Thu, 17 Jan 2013 10:57:07 +1100
Thread-Topic: [ire] RGP status data
Thread-Index: Ac30RRIIrNPU5GmuS4W/cILu8/qO/g==
Message-ID: <CD1D8352.434E8%james.mitchell@ausregistry.com.au>
In-Reply-To: <CANfbgbZe2=Ut35HO+4+-XsxkVMr4JzFuV41AgY8y80ZzxYvb2w@mail.gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.5.121010
acceptlanguage: en-US, en-AU
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [ire] RGP status data
X-BeenThere: ire@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 16 Jan 2013 23:57:17 -0000

Response inline below.

On 17/01/13 6:55 AM, "Christopher Browne" <cbbrowne@afilias.info> wrote:

>Version 01 of the arias/noguchi draft introduced the
><rdeDomain:rgpStatus> element, which
>extracts the registry grace period status values defined in RFC 3915.
>
>Some of our folks have been questioning whether these statuses are of
>much use; the initial
>concerns were rather implementation-specific, but after further
>reflection, I am wondering if
><rdeDomain:rgpStatus> is of any actual practical use.
>
>For instance, consider the "addPeriod" value, which, according to
>3915, indicates:
>
>      This grace period is provided after the initial
>      registration of a domain name.  If the domain name is deleted by
>      the registrar during this period, the registry provides a credit
>      to the registrar for the cost of the registration.
>
>In order for addPeriod to be of any real use, there are *three* things
>that need to be
>known:
>a) That it's present (which the IRE draft captures), but also
>b) What its duration is to be, that is, when should the status expire, and
>c) How much was the cost of the registration that is to be refunded.
>
>The IRE draft captures neither the temporal information nor the cost,
>which
>seems to seriously undermine the value of having "addPeriod" altogether.
>The same issue applies in much the same way to autorenewPeriod,
>renewPeriod and transferPeriod.
>
>It's not quite the same for redemptionPeriod, pendingRestore, and
>pendingDelete; for those RGP statuses, there is no amount to be refunded,
>but there is still some need for a date indicating when those statuses are
>intended to expire.
>
>In view that there is nothing in the existing draft indicating any sort of
>"billing transaction" stream, I would expect that it's pretty intentional
>not
>to have costs captured in escrow.  This suggests that addPeriod,
>autorenewPeriod,  renewPeriod, and transferPeriod are of limited use,
>and I'd be favorably inclined to the argument that those RGP statuses
>aren't worth reporting, as a result.
>
>For the redemptionPeriod, pendingRestore, and pendignDelete RGP
>statuses, I'd think that, for them to be useful, the <rdeDomain:rgpStatus>
>element would need to have an attribute added indicating the expiry date
>of those statuses.
>
>Has anyone else noticed or been concerned by this issue?

Consider a 7-day pendingRestore period gives the registrar 7 days to
provide a restore report before a domain name transitions to a new
redemptionPeriod. Should the registry be non-operational for three days
during transition to an EBERO, are those three days then lost to the
registrar, giving at least 4 days for registrars to provide a restore
report? I would suggest this may be considered incorrect from a registrars
point of view. Since the EBERO operates without charging money however
this may be of no concern as the registrar could issue another restore
request.

Also, consider transfers pending at the time of transition to an EBERO.
Not giving the losing registrar the full 5 days to reject the transfer may
be against the letter/spirit of the IRTP and lead to transfer disputes.


I'm not too concerned with the absence of this information, however more
information would allow the EBERO to make better decisions. We plan to
include the period expiration date in the status element content. If
someone restoring a registry wants to make use of this information then it
will be available. I would have preferred date information was included in
the RGP RFC however.

James

>_______________________________________________
>ire mailing list
>ire@ietf.org
>https://www.ietf.org/mailman/listinfo/ire