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


To: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From: Geva Patz <geva@bbn.com>
Date: Thu, 21 Dec 2000 12:44:56 -0500
Content-Disposition: inline
In-Reply-To: <DF737E620579D411A8E400D0B77E671D7503AD@regdom-ex01.prod.netsol.com>; from shollenbeck@verisign.com on Thu, Dec 21, 2000 at 12:05:59PM -0500
Mail-Followup-To: "'ietf-provreg@cafax.se'" <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 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


Home | Date list | Subject list