RE: [ietf-provreg] RE: Grace periods

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> I agree, it wouldn't be the right thing to do to have non RGP 
> stuff in the
> existing document without changing it's name.  I guess I was 
> really asking
> is there an intent to make it a more general "grace periods" 
> document.  As
> you say this may or may not be necessary.

No, I wasn't planning on making the document a "grace periods" document.
The ones that you described outside of RGP require nothing more than status
values to indicate application of a registry policy.  RGP has real
processing requirements in addition to the status values.

One should be able to do RGP without the grace periods (and vice-versa), so
I don't think they should be combined in the same namespace (or document).

> For clarity, perhaps I should explain my understanding of the 
> "new" grace
> periods suggested in the Deletes Task Force report.  It seems 
> to all boils
> down to: a registrar being able to get a credit / refund for 
> any domain
> creation, renewal, or transfer as long as they delete the 
> domain within 5
> days of the creation, renewal, or transfer (which then leads to the
> redemption grace period except during the add grace period).
> 
> To me the "pending" status values don't really seem to describe this
> situation adequately to a registrar as they don't distinguish between
> "action not finished" and "action refundable".

Perhaps...

> I guess the most important thing is that all registries 
> implementing the
> Deletes Task Force's suggested grace periods expose this information
> consistently.  How are other people doing this at the moment?

I'm not aware of anyone that has tried expose the grace period information.
To be honest, I'm leery when it comes to producing new protocol structures
every time some ICANN task force produces a policy recommendation.  If,
however, others feel that these grace periods are sufficiently well
established in a few different TLD registries maybe it makes sense to
document them as status values.

-Scott-