From cbbrowne@afilias.info Wed Jan 16 11:55:23 2013 Return-Path: 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 ; 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 ; 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 ; 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 ) 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 ) 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 ; 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: From: Christopher Browne 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 19:55:23 -0000 Version 01 of the arias/noguchi draft introduced the 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 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 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? From fobispo@isc.org Wed Jan 16 12:21:13 2013 Return-Path: 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 3BF2A21F8AB0 for ; Wed, 16 Jan 2013 12:21:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 bguNamCC2+g6 for ; Wed, 16 Jan 2013 12:21:12 -0800 (PST) Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 769F221F8AA3 for ; Wed, 16 Jan 2013 12:21:11 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.ams1.isc.org (Postfix) with ESMTPS id 784585F9919; Wed, 16 Jan 2013 20:20:56 +0000 (UTC) (envelope-from fobispo@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1358367667; bh=BVWQ4yhPzrGAdksuTz9oAUIKKxC/10Nao0FNr/Kgu40=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=K/hvmaKpNKs5EvZV1OVZGDSbuQjIhD5v1iuGHolJMz3qDF5LnyI2eUxnsPIHi7Gzb dzJSuSMLRje7buRAK+gjJPDnb0GF9pvC8u0F7BaWYZu7GK0D5YXWU17d9dZyEeIPVa scRg5IWSOaB3h7eez8i9Gg5UNvFMaqUC6ZYZwZ2k= Received: from [IPv6:2001:4f8:3:64:d974:a55f:ead2:7d5b] (unknown [IPv6:2001:4f8:3:64:d974:a55f:ead2:7d5b]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 0C4DF216C3B; Wed, 16 Jan 2013 20:20:55 +0000 (UTC) (envelope-from fobispo@isc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Francisco Obispo In-Reply-To: Date: Wed, 16 Jan 2013 12:20:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Christopher Browne X-Mailer: Apple Mail (2.1499) Cc: ire@ietf.org 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 20:21:13 -0000 Hi Christopher, My response below: On Jan 16, 2013, at 11:55 AM, Christopher Browne = wrote: > Version 01 of the arias/noguchi draft introduced the > element, which > extracts the registry grace period status values defined in RFC 3915. >=20 > 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 > is of any actual practical use. >=20 > For instance, consider the "addPeriod" value, which, according to > 3915, indicates: >=20 > 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. >=20 > 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. >=20 Mapping Policy is something that is not currently part of any document = that we're dealing with, I believe the issue has been raised in the = past. Most likely, this is an issue that will have to be resolved using = an out-of-band mechanism. The duration of those periods, are usually bound to the various dates = that exist on EPP objets: created_date, expiry_date, etc. So perhaps it = would be useful to have some sort of "manifest" with the set of policies = that the registry implements, so that a consuming EBERO could maintain = the status quo. > 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. >=20 > 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. >=20 > 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. >=20 They are worth reporting, because it's part of the domain lifecycle, the = EBERO or consumer of this data will have to know how to apply policy to = the information being imported to the registry. > For the redemptionPeriod, pendingRestore, and pendignDelete RGP > statuses, I'd think that, for them to be useful, the = > element would need to have an attribute added indicating the expiry = date > of those statuses. >=20 Those values usually depend on the EPP object dates (creation, expiry, = etc.) > Has anyone else noticed or been concerned by this issue? > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire Francisco Obispo=20 Director of Applications and Services - ISC email: fobispo@isc.org Phone: +1 650 423 1374 || INOC-DBA *3557* NOC PGP KeyID =3D B38DB1BE From james.mitchell@ausregistry.com.au Wed Jan 16 15:57:17 2013 Return-Path: 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 ; 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 ; 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 ; 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 To: Christopher Browne , "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: In-Reply-To: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" wrote: >Version 01 of the arias/noguchi draft introduced the > 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 > 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 >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