Discipline of Internet Protocol Engineering

Harald Tveit Alvestrand harald at alvestrand.no
Wed Jun 4 12:16:13 CEST 2003

--On tirsdag, juni 03, 2003 15:27:25 -0700 Dave Crocker <dhc at dcrocker.net> 

> KM> The reason I say this is that several groups have demonstrated the
> inability KM> to define the problem they are working on,
> Unfortunately, i think this problem is deeper than we might wish to
> acknowledge.  I tend to be a charter fascist, on the theory that a
> crystal clear charter will leave no doubt about the problem being
> solved, and/or the benefit to be derived from the result and the
> deliverables to be produced.
> I view charters as real contracts, making clear what is included and
> obligated and what is excluded and prohibited.
> However with great regularity, remarkably fuzzy charters are getting
> approved. since chartering involves lots of experienced people beyond
> the working group, we can't simply assess the problem on the working
> group folk.


this is a problem, not only because we have different opinions on what WGs 
should do, but because we have different opinions on what "fuzzy" means.

Take, for instance, the recent LEMONADE charter - which I think is 
reasonably crisp and states what the WG is intended to do.

When it was first floated on the IETF list, it was blasted by at least a 
couple of people (including you, I think) as being fuzzy, unreadable and an 
improper tool for evaluating or constraining the work of the group.
(Yes, there were improvements. But I think the first version floated wasn't 
that bad either.... and the intent of the proposers didn't change one whit, 
as far as I know; it just became expressed more clearly.)

Or take the charter of this working group. I simply did not see a way to 
describe the work to be done by this working group more precisely, without 
unduly constraining the problem area it was "permitted" to explore - a 
constraint I felt at the time that it was quite important for the IESG 
*not* to apply.

What's a charter that you view as a "good model"?


More information about the Problem-statement mailing list