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

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

Geza,

I can come up with some text for section two to describe the object
extensibility goal.  The first sentence described below seems like a good
starting point.

I think I misread one piece of your most recent proposal (reading
"registrars" where you wrote "registries").  The way you characterized the
requirement mapping in your last paragraph gives me an idea, though - why
not phrase the requirement like this:

[2] The protocol MUST allow a registry to implement policies allowing a
range of domain registration time periods, where registrars MAY choose to
offer (not necessarily identical) subsets of the range of periods, and where
registrants get to choose an element from that subset.

Scott Hollenbeck
VeriSign Global Registry Services

-----Original Message-----
From: Geva Patz [mailto:geva@bbn.com]
Sent: Thursday, December 21, 2000 12:45 PM
To: 'ietf-provreg@cafax.se'
Subject: Re: Expiration times [was Re: domreg BOF Meeting Minutes]


On Thu, Dec 21, 2000 at 12:05:59PM -0500, Hollenbeck, Scott wrote:
> 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'll buy that. I'd like to see a reference to the idea somewat earlier in
the document, too, just to emphasize the point (section 2 seems a prime
candidate for such rewriting).

> 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'm not for the introduction of cruft. Rather, I'm against the 
introduction of arbitrary restictions. Our ultimate goal, after
all, is to create a protocol that will become an Internet standard.
To be useful as a standard, it ought to accommodate a wide range
of registration application with as wide range of policy models (within,
of course, the overall scope of the type of application we're trying to
support). The Internet is large, diverse and global, so if we have any
aspirations to standardhood, we must take the responsibility of serving
that wider audience seriously. 

For an example of the registration model I described, where a registry
implements a policy allowing a range of time periods, where registrars 
choose to offer (not necessarily identical) subsets of the range of
periods, and where registrants get to choose an element from that 
subset, may I refer you to the gTLDs '.com', '.net' or '.org', where
precisely such a mechanism is currently in place. ;)

-- Geva