[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: Thu, 21 Dec 2000 09:31:08 -0500
Content-Disposition: inline
In-Reply-To: <DF737E620579D411A8E400D0B77E671D7503A7@regdom-ex01.prod.netsol.com>; from shollenbeck@verisign.com on Thu, Dec 21, 2000 at 07:39:13AM -0500
Mail-Followup-To: 'provreg List' <ietf-provreg@cafax.se>
Reply-To: ietf-provreg@cafax.se
Sender: owner-ietf-provreg@cafax.se
User-Agent: Mutt/1.2.5i
Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes]

On Thu, Dec 21, 2000 at 07:39:13AM -0500, Hollenbeck, Scott wrote:
> 
> 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'm not sure that I agree. 7.5-[1] states (sensibly) that "A:,
generic registry-registrar protocol SHOULD provide features
that at a minimum allow for the management of new object types
without requiring revisions to the protocol itself". There's a
subtle difference in sense between this, which basically suggests
that the protocol be extensible, and my proposed rewording of
3.4-[1], which suggests that the protocol should be designed from
the outset to accommodate a broader range of identifiers than
domain names (which the EPP proposal, for instance, does). I
won't re-hash the reasons why we changed the name from `domreg'
to `provreg', but I think it's important to capture those in the
requirements.


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

A fair point, except that several other parts of the requirements draft
get into exactly such issues. For instance 3.3-[1]:

" Registry operations that create, update, or delete objects MUST be
  associated with a registry-unique transaction identifier.  The
  identifier SHOULD be created using the current date and a combination
  of identification information assigned by and unique to the registry
  (such as a registrar identifier) and information assigned by and
  unique to the registrar requesting the operation (such as a coded
  combination of letters and numbers)." 

On your principle (which certainly has merit), this should probably
be re-worded something along the lines of:

" The protocol MUST allow each transaction to be identified in a 
  permanent and globally unique manner"

There are several other examples elswehere in the text. I think we need
to decide as a group where we'd like the requirements to be, and if we
decide to come down firmly on the side of "what, not how" (which, again,
I don't think is a bad idea), then we'd best go through the draft in 
some detail to make sure that it adheres to that principle.

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

... except that the value may not be determined by registry
policy, but by registrar policy (or by registrant request).
All registries have a policy, even if only by implication
("we'll register anything"), but that policy doesn't necessarily
determine the value. Consider a registry policy of "We will
register identifiers for any finite length of time, provided
that the time is paid for up front at the rate of $0.03/day".
The only constraints that this imposes is disallowing indefinite
registrations, and setting the resolution of time periods in
days. Now suppose a registrar in that domain has the policy that
"We'll register names for 1 year at $x, 2 years at $y, or 5 years
at $z". That further constrains the periods to the set {1 year; 
2 years; 5 years}, but _still_ doesn't determine the period, until
a registrant choses a specific value. The registrant/registrar
negotiation is (probably) out of our scope, but the idea that the
registrar (optionally) determines the expiration date, which the
registry may reject, is an important one.

So, we could have wording like this:

[1] The protocol MUST provide services to register unique
alphanumeric identifiers, in particluar Internet domain names

[2] Identifiers MUST be registered for an unambiguous period
(which MAY be indefinite if registry policy allows). The protocol
MUST allow registries to specify a start and end time for the
registration period on behalf of the registrant, and MUST allow
the registry, depending on its policy, to confirm the proposed
period, reject it, or specify a default period if the proposal is
omitted.

-- Geva


Home | Date list | Subject list