Re: Expiration times [was Re: domreg BOF Meeting Minutes]

[Mike Lampson IARegistry <lampson@iaregistry.com>]

I like the changes being recommended here.  A couple of questions:

1) Should we use "expiration timestamp" instead of "expiration date" for
conciseness?

2) Should the requirements state that if objects require an expiration date
by policy, then those objects {MUST?/SHOULD?} have a policy-defined default
when an expiration timestamp or forward delta is not provided?

Cheers,

_Mike
--
Mike Lampson
The Registry at Info Avenue, LLC
(803) 802-6584

----- Original Message ----- 
From: "Geva Patz" <geva@bbn.com>
To: "'provreg List'" <ietf-provreg@cafax.se>
Sent: Wednesday, December 20, 2000 3:25 PM
Subject: Expiration times [was Re: domreg BOF Meeting Minutes]


> OK, given the chorus of approval on the idea that the
> registration period wording  needs to change, here's a proposal
> for some specific wording. How about changing this:
> 
> < [1] The protocol MUST provide services to register Internet domain
> <  names.  The registration period for domain names MUST be measured in
> <  years, with a minimum period of one year and a maximum period defined
> <  by registry policy.
> 
> Into this:
> 
> > [1] The protocol MUST provide services to register Internet domain
> > names, and SHOULD allow for the registration of other unique
> > alphanumeric identifiers.
> >
> > [2] The protocol MUST allow registrars to specify an optional 
> > expiration date for each object registered, and MUST allow 
> > registries to accept or reject the proposed expiration date based
> > on their local policies. Dates MAY be specified either as
> > absolute times or as forward deltas from the time of actual
> > registration. 
> 
> Notice that I've sneaked a few other things into here, too, besides
> the relaxation of the exiration requirement:
> 
> * I've hinted at the more general applicability of the protocol in
>   the SHOULD clause of [1]
> 
> * I've moved the focus of specifying an expiration date from the 
>   registry to the registrar, while still allowing the registry to 
>   have ultimate policy control over the duration of registrations. 
>   This, to my mind, better mirrors the situation in the real world,
>   where different registrars offer different periods of initial 
>   registration in the same TLD, sometimes for different prices. 
> 
> * I've made the expiration date optional, to cater for the case
>   where objects are registered indefinitely (rare for domain names,
>   common in some other identifier spaces). 
> 
> * I've added a hint that protocol designers may wish to consider
>   time deltas. This seems to make more sense if you've got registrars
>   proposing expiry times, to allow for network delays and clock skews. 
>   To illustrate the issue here, consider a registrar asking for a 
>   one-year registration from a registry whose policy allows
>   registrations only in one-year increments, where the registrar's
>   clock is behind the registry's by m minutes, and where network 
>   congestion induces an n-minute delay in transmission. Given an 
>   absolute time, the registry may reject the request as being (n+m) 
>   minutes short of a year.
> 
> -- Geva
>