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