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


To: "Jörg Bauer/Denic" <bauer@denic.de>, "Edward Lewis" <lewis@tislabs.com>
Cc: <ietf-provreg@cafax.se>, <lewis@tislabs.com>
From: "Brian W. Spolarich" <briansp@walid.com>
Date: Wed, 21 Mar 2001 16:17:33 -0600
Importance: Normal
In-Reply-To: <OFBE177419.B8D9D529-ONC1256A15.00592F33@denic.de>
Sender: owner-ietf-provreg@cafax.se
Subject: RE: Antwort: Pre-meeting notes


| > 4) One of the issues raised in the drafting of the charter is
| > extensibility.  I feel that although the requirements document mentions
| > this, extensibility isn't being addresses enough.  Are there a few folks
| > (say 2-3) that would be willing to be a "design team" to keep an eye on
| > extensibilty?  I'm looking towards the folks that most vocally supported
| > the use of the protocol for not-just-DNS registrations.
| >
| > Q: Do we need this / who wants to volunteer?
|
| I realy want that the protocol isn´t just usefull for domainnames, but i
| think we first should concentrate on domainnames because there is the
| biggest need for a protocol.
|
| It´s important that the protocol has that ability to be extended but i
| think this is something for version 2.
| Maybe it´s easier to define the requirement of this extensibility with the
| experience of a working system.

  Perhaps one way of approaching this is defining what things
the protocol is NOT intented to be extensible to do.

  That is to say, it is very difficult to predict how a given thing will
be used by users, but it is useful to define the kinds of activities
that thing should be used for, and also explicitly what it is not intended
to do.

  An important goal here is to be extensible.  Fair enough, but
I think we need to constrain the design space, otherwise we could
wind up with never-ending "feature creep".  Saying what the
protocol should not be used for might be a good way to do that.

  -bws


Home | Date list | Subject list