Discipline of Internet Protocol Engineering

[Dave Crocker]

Folks,


JA> However, I believe there's a more fundamental reason why some
JA> charters are or may need to be fuzzy. That reason has to do with the
JA> timing when the IETF gets involved, or the scope of the problem.

This has been discussed over the years. We sometimes form working groups
without really knowing what they are supposed to do.

I believe that a working group must formulate its requirements statement
before forming or within a few months. Otherwise it is not ready to do
standards work. The IETF has a very poor track record with fuzzy goals,
and a very good one with very concrete, very near-term and very narrow
goals.


JA> Are you doing adding a new algorithm to an existing security
JA> protocol? Pretty specific. Are you going to develop a protocol for a
JA> specific purpose? Still pretty simple.

agree.


JA> Are you going to develop a whole set of protocols and extensions to
JA> fulfill a function. Starting to get more complex (example: SIP). Are
JA> you going to re-architect IPn and develop IPn+2? Pretty tough

Not just tough but I would say that our track record for such
large-scale project is quite poor, unless we have been able to carve off
pieces that are useful on their own.

That is, if we can do incrementally useful work, then the IETF has a
good chance of doing something that is timely and useful. Otherwise, we
don't. Our work suffers from technical and schedule bloat.



HTA> Take, for instance, the recent LEMONADE charter - which I think is
HTA> reasonably crisp and states what the WG is intended to do.
HTA> When it was first floated on the IETF list, it was blasted by at least a
HTA> couple of people (including you, I think)

Yes. However what I found interesting was that the fundamental concerns
about concreteness that I was raising did not seem to be that
interesting to most folks. Pete Resnick did a stellar job of negotiating
a compromise, but that should not have been necessary.

All I was seeking was a charter that said concretely what
problem/benefit was being attacked, and what the technical scope of work
would be, in language that permitted knowing what was *out* of scope as
much as what was *in* and knowing what would actually be delivered.


HTA> Yes, there were improvements. But I think the first version floated wasn't
HTA> that bad either

My sense is that looking at the history of that charter could be highly
instructive, since my impression is that some iterations of it received
"help" that made it considerably more mushy, in the earlier stages.



KM> Part of the problem may be that we often want the initial charter to map
KM> out the entire life cycle of the group.  often this is unrealistic, because
KM> we really don't understand what the group has to do.  I don't think we
KM> should try to nail down details more than about eight months (say two
KM> IETF meetings) in advance.  But if we don't have a good idea about what
KM> a WG is going to be doing over the next few months, with fairly concrete,
KM> realizable, measurable goals - something's wrong.

Folks -- we need to frame Keith's words and chant them at the beginning
of every meeting -- and it just kills me to say something this nice
about Keith.


JA> We could in addition require that groups produce something concrete
JA> (like an approved document) in that 8 months.

Note that the PACT suggestion was 18 months, yet folks were quite upset
about it.



HTA> Might part of the problem be that we're lousy at making plans, *apart* from
HTA> the charter?
HTA> I don't think I've ever seen a working group chair come up with a
HTA> document/message/webpage that said something like "OK, in order to achieve
HTA> this milestone in December, here's what we're planning to do in June, July,
HTA> August, September and November

Properly designed milestones will, at least, set the stage for exactly
that kind of thinking.  Or perhaps the way to talk about this is that
you are calling for the intermediate milestones that will achieve the
ones in the charter.

Egad. As you note, this starts sounding like classic project management.

What a thought.

d/
--
 Dave Crocker <mailto:dcrocker at brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>