OPEN ISSUE: Standards Track

Jari Arkko jari.arkko at piuha.net
Fri May 23 10:30:10 CEST 2003


Charlie Perkins wrote:

> I'm afraid this may be getting away from the original point,
> which is that there needs to be a way to boil a truckload
> of water before we boil the ocean.
> 
> The idea of requiring a threat analysis and deployment
> scenarios analysis is a pretty good way to raise the bar
> way up into the stratosphere so that no work gets done.
> Presumably you meant that this would come _after_
> the problem statement and definition, followed by the
> requirements analysis, all of which should (???) occur
> before anyone is allowed to mention a solution.

(This is starting to sound a lot like the operation of
the problem WG...)

I very much agree with you about boiling the ocean.
And about including interoperability and implementation
experience along the way. The current IETF mindset
resembles the waterfall software engineering model:
lengthy release cycle, a lot of new features in releases,
emphasis on planning, review, and quality control.

I agree that adding at least some amount of iterative
process thinking would be good. I view this mainly as
starting with a smaller set of functionality than
improving scalability of solutions at a later stage,
however. In short: we need to have scalable, secure,
and otherwise quality protocols. But we may not need
them to have all features. Looking at the planned
future work in the charters of the MIPv4/MIPv6/MIPSHOP
WGs, it looks like we are now using an iterative
and parallel approach. Very good!

--Jari

P.S. Here's an exercise for the day: calculate an
estimated completion date for the problem WG when it
starts with the following: (a) full enumeration
of all problems of the IETF, (b) banning discussion of
"running code" i.e. solutions, (c) enumeration of
all core values that may not be broken as a result of
modifications, (d) lengthy discussion about the
process-changing process. This will have to be
followed by a discussion which picks the problems
and solutions that will be solved, the development
of the detailed solutions, and getting them approved
and deployed.



More information about the Problem-statement mailing list