Discipline of Internet Protocol Engineering

Jeanette Hofmann jeanette at wz-berlin.de
Wed Jun 4 17:57:39 CEST 2003

On 4 Jun 2003 at 16:44, Harald Tveit Alvestrand wrote:

> --On onsdag, juni 04, 2003 10:25:00 -0400 Keith Moore <moore at cs.utk.edu> 
> wrote:
> >> However, I believe
> >> there's a more fundamental reason why some charters are or may
> >> need to be fuzzy. That reason has to do with the timing when
> >> the IETF gets involved, or the scope of the problem.
> >
> > Part of the problem may be that we often want the initial charter to map
> > out the entire life cycle of the group.  often this is unrealistic,
> > because we really don't understand what the group has to do.  I don't
> > think we  should try to nail down details more than about eight months
> > (say two  IETF meetings) in advance.  But if we don't have a good idea
> > about what a WG is going to be doing over the next few months, with
> > fairly concrete, realizable, measurable goals - something's wrong.
> >
> Might part of the problem be that we're lousy at making plans, *apart* from 
> the charter?

I think we are dealing with two more or less unrelated issues here. One 
has to do with the observation of Dorothy L. Sayers that "facts are like 
cows. If you look them in the face hard enough they generally run away." 
Some flexibility regarding both tasks and time is necessary to be prepared 
for unexpected running cows or facts. 

The other issue is general time management. The working groups seem 
not apply what most of their members would do under similar 
circumstances in their day job. 


> I don't think I've ever seen a working group chair come up with a 
> document/message/webpage that said something like "OK, in order to achieve 
> this milestone in December, here's what we're planning to do in June, July, 
> August, September and November.... we didn't do what we were supposed to do 
> in May, so that means September's going to have a time crunch....."
> again, this is something we have no rule against, it's normal practice in 
> other branches of engineering, but we just don't seem to be doing it....

More information about the Problem-statement mailing list