[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "'provreg List'" <ietf-provreg@cafax.se>
From: Geva Patz <geva@bbn.com>
Date: Wed, 20 Dec 2000 15:25:44 -0500
Content-Disposition: inline
In-Reply-To: <008001c06abd$9a073260$140a0a0a@ambler.net>; from cambler-ietf@iodesign.com on Wed, Dec 20, 2000 at 11:46:51AM -0800
Mail-Followup-To: 'provreg List' <ietf-provreg@cafax.se>
Reply-To: ieft-provreg@cafax.se
Sender: owner-ietf-provreg@cafax.se
User-Agent: Mutt/1.2.5i
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


Home | Date list | Subject list