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


To: "'provreg List'" <ietf-provreg@cafax.se>
From: "Jordyn A. Buchanan" <jordyn@register.com>
Date: Thu, 21 Dec 2000 10:06:37 -0500
In-Reply-To: <20001221093108.B38157@bruno.bbn.com>
Sender: owner-ietf-provreg@cafax.se
Subject: Scope [was Re: Expiration times]

At 09:31 AM 12/21/2000 -0500, Geva Patz wrote:
>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.

This is a valid point.  At the same time, I think it's important to avoid 
too much scope creep here too.  One thing we should get a handle on is 
"what types of registrations do we want the initial requirements document 
to cover?"  Some specificity on this issue allows us to craft good 
requirements throughout the rest of the document.  We should keep 
extensibility in mind, obviously, because I don't think anyone wants to end 
up with a protocol that only registers domain names, but at the same time 
we don't want to end up with the "generic database update protocol", either.

>[snip]
>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 agree.  The principle is good, and it should be applied throughout the 
requirements document.


>[snip]
>So, we could have wording like this:
>
>[1] The protocol MUST provide services to register unique
>alphanumeric identifiers, in particluar Internet domain names

As above, can we tighten this up?  I'd suggest wording, but I think we need 
to agree about the scope of our efforts first.  This may determine how we 
think about our approach to the subsequent requirements.

To jump start this conversation, here are things that people have suggested 
we might want the protocol to register:

- Domain names
- IP address ranges
- AS numbers

Should we try to deal with all of these?  Are there things not on this list 
that we want to try to deal with?

Jordyn


Home | Date list | Subject list