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

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

Rather than try to enumerate all of the possible object types that might be
registerable as suggested by Jordyn or generalizing 3.4-[1] as suggested by
Geva (which I think would then be inconsistent with other specific object
requirements in 3.4), I'd really prefer to add a requirement to section 7.5
if people believe that 7.5-[1] talks more to protocol extensibility than
object extensibility:

"[2] The requirements described in this document are not intended to limit
the set of objects that may be managed by a generic registry-registrar
protocol.  A generic protocol MUST include features that allow extension to
object types that are not described in this document."

I would prefer to see this kind of global statement in section 7.5 than in
section 3.4 because 3.4 describes object registration only.  If we add such
a statement to 3.4, I think we have to add similar statements to 3.5, 3.6,
3.7, 3.8, 3.9, 3.10, and 3.11 to be consistent.  I'd like to keep 3.4-[1]
limited to domain names as in:

> [1] The protocol MUST provide services to register Internet domain
> names.

while creating a new 3.4-[2] that deals with the registration period.  WRT
to [2] as suggested below, I would really like to understand which
registries support the registration model as described.  I'm all for
architectural agility, but I would prefer to work with current real-world
requirements vs. trying to guess what might be done in the future to avoid
kruft introduction.

I fully agree that any other descriptions in the document that describe a
"how" should be generalized into a "what".  There's also something that
smells like a "how" in section 8.4; I'll fix that.  Identification of other
offending sections is welcome.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Geva Patz [mailto:geva@bbn.com]
Sent: Thursday, December 21, 2000 9:31 AM
To: 'provreg List'
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