[ire] RGP status data
Christopher Browne <cbbrowne@afilias.info> Wed, 16 January 2013 19:55 UTC
Return-Path: <cbbrowne@afilias.info>
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 51C0E21F8AE6 for <ire@ietfa.amsl.com>; Wed, 16 Jan 2013 11:55:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 sjqrIPE5rHte for <ire@ietfa.amsl.com>; Wed, 16 Jan 2013 11:55:22 -0800 (PST)
Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id BF3E621F8A61 for <ire@ietf.org>; Wed, 16 Jan 2013 11:55:22 -0800 (PST)
Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from <cbbrowne@afilias.info>) id 1TvZ4z-0004jD-66 for ire@ietf.org; Wed, 16 Jan 2013 19:55:21 +0000
Received: from mail-vb0-f70.google.com ([209.85.212.70]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from <cbbrowne@afilias.info>) id 1TvZ4z-0000Ue-5q for ire@ietf.org; Wed, 16 Jan 2013 19:55:21 +0000
Received: by mail-vb0-f70.google.com with SMTP id ff1so2523170vbb.5 for <ire@ietf.org>; Wed, 16 Jan 2013 11:55:16 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=2fJ/RIUMnXARRejnYY70LNYtnmobaKdVrD53aCq9Je0=; b=JaY+NY9+NL/hNsyBHfhenpBXb7xf0VTLyGrhgKu9Io8hH7IX1Y3j8Ec8zHKBoafd0G uk8kDsdZ3rBqJDo/NyeYBhGjLi/CiHSrOJroVuiHml1i2PiNP4wLiR8NIen4xIlQv3mM ARCLEpa/shJQ8H47SGFqkMn1LCujz/5zb6jbqzfE9c0gDwJB9ViREXUKr+YTKxXZVsNi BFT0eOIQ8Nq8Jy+kglgCccsNKooT2vpM7ej8y63G31z6DRZutKxx5pBAKc9gs7kiutto 6Yqz32YY3eUCgn6LXWL4diPbzdvrnjP6/HqXlp4YZKtd/dcP8jqm7RjXwT4EHY75K4iQ vQTw==
X-Received: by 10.224.138.143 with SMTP id a15mr2948223qau.91.1358366116300; Wed, 16 Jan 2013 11:55:16 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.224.138.143 with SMTP id a15mr2948211qau.91.1358366116127; Wed, 16 Jan 2013 11:55:16 -0800 (PST)
Received: by 10.49.13.106 with HTTP; Wed, 16 Jan 2013 11:55:16 -0800 (PST)
Date: Wed, 16 Jan 2013 14:55:16 -0500
Message-ID: <CANfbgbZe2=Ut35HO+4+-XsxkVMr4JzFuV41AgY8y80ZzxYvb2w@mail.gmail.com>
From: Christopher Browne <cbbrowne@afilias.info>
To: ire@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQnX1LcX0c29vAFIAxNF3sF2QMkuXW4vQHWPPnnaP/q8iJSMlogGnpV/scptgTnjvOLz9JtNscuQWYV9WfCeljDi1v/bx7XWJgZS10jfkGJ/xjVY941ipoBdxs5kuxSGsTEZvIvT
Subject: [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 19:55:23 -0000
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?
- [ire] RGP status data Christopher Browne
- Re: [ire] RGP status data Francisco Obispo
- Re: [ire] RGP status data James Mitchell