To:
"'provreg List'" <ietf-provreg@cafax.se>
From:
"Hollenbeck, Scott" <shollenbeck@verisign.com>
Date:
Thu, 21 Dec 2000 07:39:13 -0500
Sender:
owner-ietf-provreg@cafax.se
Subject:
RE: Expiration times [was Re: domreg BOF Meeting Minutes]
I have a minor objection to [1] and a fundamental objection to [2]. I'll explain my minor objection first. Requirement 7.5-[1] already exists to ensure that the protocol allows for registration of objects not explicitly specified in the draft, so I think the second sentence is redundant. I agree with altering the current second sentence of 3.4-[1] (the "registration period" sentence) and will propose new text in a moment. My immediate objection to [2] isn't with the suggested concept, though I do have a philosophical objection to it that we can take that up when we start to talk protocol. The requirements draft describes functional requirements, which I have interpreted to mean "requirements for _what_ the protocol is supposed to do". I believe the suggested new text is getting into the specifics of _how_ the protocol is supposed to solve a particular issue, and is thus out of place in this document. I think it would be more appropriate to say something along the lines of "a domain name must have a registration period whose value is determined by registry policy". Here's what I propose for new text: [1] The protocol MUST provide services to register Internet domain names with a well defined registration period. [2] The protocol MUST provide minimum and maximum values for a domain name registration period that allow the period to be determined by registry policy. This new text describes "what" the protocol is supposed to do without getting into "how" it should be implemented, or imposing limits based on any current policy. Scott Hollenbeck VeriSign Global Registry Services -----Original Message----- From: Geva Patz [mailto:geva@bbn.com] Sent: Wednesday, December 20, 2000 3:26 PM To: 'provreg List' 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