Doing the Right Things?
moore at cs.utk.edu
Mon Jun 2 12:09:52 CEST 2003
> > 1. We need to define the discipline of Internet Protocol
> > Engineering.
> > By that, I mean we need to enumerate a series of steps that should
> > normally be followed, more or less in order, when developing or
> > modifying a protocol for use on the Internet. It doesn't have to be
> > a long or complicated set of steps, and it doesn't have to be rigid.
> > The main thing
> > is to establish that (for instance) you really do need to understand
> > your threat model and choose a security technology *before* you
> > design your protocol - or (for instance) the time to identify other
> > parties that your protocol might effect and work out compromises
> > about how to minimize adverse impact is *before* you do detailed
> > protocol design or tweaking. And maybe it would include
> > 'prototyping' as one of the steps to occur before standardizing.
> > (though this doesn't mean that the prototype has to implement all
> > features of the standard)
> I agree with you on this. This almost seems like a roadmap. I think
> in the past, charters have served this function, in an informal way,
> but I think having a loose, but more formal roadmap (for lack of a
> better term) for the work we undertake in the IETF would be a good
note also that this 'roadmap' is independent of working group processes
- that is, it doesn't matter whether the engineering is being done
by a working group or a group of individuals or a single person -
these are steps you need to follow regardless. so while the roadmap
might end up imposing some guidelines or constraints for WG operation,
it shoudn't be thought of strictly in terms of WG operation.
More information about the Problem-statement