kre at munnari.OZ.AU
Tue Feb 4 23:38:12 CET 2003
Date: Tue, 04 Feb 2003 16:02:26 +0100
From: Brian E Carpenter <brian at hursley.ibm.com>
Message-ID: <3E3FD602.64C2B385 at hursley.ibm.com>
| Provocative answer: when they suspect that the proponents
| of a new protocol design are confused about their goals.
I suspect that tends to be (in practice) interpreted more as
When they think that the proponents of a new protocol
might be confused about their goals.
Then doing the requirements will help determine if they are confused
or not, and if they are, perhaps eliminate some of the confusion.
The problem comes because it is obvious that anyone might be confused,
and so it is very easy to then say to everyone "write a requirements doc".
That takes not much investigation, and seems safe.
Actually determining if the (proposed) WG is confused or not takes a lot
of investigation, and the people being asked to do this are currently
way overloaded by other stuff already - hence I suspect find it easy to
adopt the "well they might be confused" approach, and simply ask for
a requirements doc all the time.
Take the (proposed) lemonade WG that has just recently been discussed.
I'm not part of that effort, but from what I saw of its intended charter,
it looks as if they have already pretty much determined just what
problems they're intending to handle, and even in some cases the general
direction of the solution (if anything the charter makes it appear that
some of the work is essentially done, and just needs approving).
Yet the first milestone on their list is to write a requirements doc.
That seems (in that particular case) like a colossal waste of time to me.
| No, if a *change* to existing protocols is proposed, it seems
| to me less likely that a requirements draft will be essential.
The comment you're replying to seemed to agree that what you say makes
sense, but it isn't being observed in practice.
| It's always a good idea to know what the problem is before
| solving it.
| Whether we always need to write down formal
| requirements is what we are debating here.
In most cases, there should be enough of the requirements in the
charter - that's supposed to set out what the group is to do. If
they have no idea, they can't really write a reasonable charter.
There are certainly times when some considerable effort is needed to
work out what the problem actually is, and to define the characteristics
of a successful solution to that problem, which will then allow the WG
to measure its progress by determining how close to success by that
definition that have come, but this really should be a rarity. Most times
if the group can write a charter that specifies what it is to do,
that should be enough.
ps: this WG (or mailing list or whatever it is) is another example of a
WG that has been created just to write a requirements doc (or something
closely enough related to that to be almost indistinguishable). That's
a difficult thing to do for any technical WG (where often the requirement
comes close enough to implying the solution that it is hard to separate),
but downright dangerous for a process WG like this one - it gives the
impression that if those in charge don't like the requirements that this
group produces, (ie: can see what the obvious way to solve the problems
identified, and don't like that) then they simply won't allow a WG to
actually define the solution (make the IETF process changes) to be created.
If it is to be guaranteed that a WG will be created to solve any problems
identified here, then it might just as well be this group.
More information about the Problem-statement