Re: [ire] RGP status data

[Francisco Obispo <[e-mail]>]

Hi Christopher,

My response below:

On Jan 16, 2013, at 11:55 AM, Christopher Browne <[e-mail]> 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.
> 

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.
> 
> 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.
> 

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 <rdeDomain:rgpStatus>
> element would need to have an attribute added indicating the expiry date
> of those statuses.
> 

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ire

Francisco Obispo 
Director of Applications and Services - ISC
email: [e-mail]
Phone: [phone] || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE