Discipline of Internet Protocol Engineering

[Keith Moore]

> KM> 1. We need to define the discipline of Internet Protocol Engineering.
> 
> KM> By that, I mean we need to enumerate a series of steps that should
> KM> normally be followed, more or less in order, when developing or
> KM> modifying a protocol for use on the Internet.
> 
> Hmmm.  We have "guidelines" for working group process.  Perhaps you are
> suggesting "guidelines" for protocol development?  

yes, this is approximately what I have in mind - at least as I understand
it at present.  I liked the term "roadmap" that someone else suggested also.

> KM> The reason I say this is that several groups have demonstrated the
> KM> inability 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.
...
> 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.

My view is that we often don't have enough understanding of the problem at
the time a WG is chartered to insist that the charter be very precise or
detailed.  And charter refinement is yet another thing that takes up IESG
resources.  Also, asking groups to write "requirements" documents (or as I
would prefer, "design goals" documents) hasn't worked well either as far as I
can tell - groups don't seem to understand the purpose behind this task or how
to do it.  

So we need to find a better way to refine WGs' problem definitions.