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

Re: Requirements process suggestions



Good ideas.

One plea: can we start with the scenarios? They should be key
in helping to drive the itemized requirements list.  We can't
afford another "accommodate a subset of the scenarios and
shoehorn in later the stuff we forgot".

As I said in MSP, the WG needs to determine the following:
(a) do the listed scenarios (admittedly some of them not
all that well fleshed-out) the ones we want to be the list
of core scenarios for SOI?  What needs to be added? What
needs to be removed?

The core scenarios represent the things that *must* be
accommodated by SOI and its companion protocols. If
a scenario is in the list, and we don't meet it's needs,
we've failed.  [And we also don't want to expend a lot
of excess energy on scenarios that the WG doesn't feel
are important.]

(b) I attempted a model to represent the key needs for each
scenario. Is the model reasonable? Sufficient?

(c) Look at the scenarios themselves. What's missing? What's
incorrect?

I desperately need help in fleshing out the mobile ip/wireless
and IPv6 scenarios (v6 isn't simply a larger address; we need
to start becoming more intelligent in addressing that problem
space). I am hearing from certain folks that IPsec is a poor fit
for these problem spaces; if so, now's the chance to influence
future design. [In other words, those who care need to put some
skin in the game...]


When we make reasonable forward progress on the scenarios,
I'll feel more comfortable about discussing the requirement line
items...

thx - C



At 09:44 AM 3/27/2002, Michael Richardson wrote:

> >>>>> "Melinda" == Melinda Shore <mshore@cisco.com> writes:
>     Melinda> The requirements process doesn't seem to be going very well,
>     Melinda> which isn't that surprising - requirements documents are hard
>     Melinda> to do.  I think it might be possible to have the son-of-IKE
>     Melinda> requirements through WG last call before Yokohama
>     Melinda> by applying some discipline, if that's what the working group
>     Melinda> wants.
>
>     Melinda> In particular, it's impossible to develop a good requirements
>     Melinda> document by evaluating it in terms of whether or not it presents
>     Melinda> a harmonious, pleasing whole.  It's got to be taken apart and
>     Melinda> put back together again.  What I've found to be effective (but
>     Melinda> a lot of work) is:
>
>     Melinda> 1) take the requirements document, turn it into a numbered
>     Melinda>    list of crisp, declarative sentences
>     Melinda> 2) make a quick first pass through the list and identify items
>     Melinda>    on which there's already consensus either to keep or to
>     Melinda>    drop.  If there's any - *any* - disagreement about anything,
>     Melinda>    it goes on the "unresolved" list.
>
>   Yes, I agree with this process. Make three lists:
>   a) requirement is in scope           (no debate)
>   b) requirement is out of scope       (it may never be discussed again)
>   c) requirement is eligble for debate.
>
>     Melinda> I've found that the only thing that requires face-to-face 
> interaction
>     Melinda> is item 2 - doing it on the mailing list is too 
> slow.  However, given
>     Melinda> the 30-day-notice requirement for interim meetings waiting 
> for an
>     Melinda> interim meeting may take too long, too, and perhaps instead 
> everything
>     Melinda> could go on the unresolved list.  It's a lot of work for the 
> chairs
>
>   We should start on the mailing list anyway.
>
>   I am willing to keep track of the list.
>
>]       ON HUMILITY: to err is human. To moo, 
>bovine.           |  firewalls  [
>]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net 
>architect[
>] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device 
>driver[
>] panic("Just another NetBSD/notebook using, kernel hacking, security 
>guy");  [


====================================
Cheryl Madson
Core IP Engineering; Security and Services
Cisco Systems, Inc.
cmadson@cisco.com