In general we need to discourage the meme "requirements documents".
No, we don't. We just need to discourage the practice of waiting to write
such a document until after protocol design is complete, rather than doing
it first.
Disagree. Unlike engineering of physical objects, very few things
that we do in IETF are tied to physical phenomena that can be measured
with precision and have inherent limits. If you're designing
IP-over-foo, you might be dealing with physical characteristics of foo
(like maximum link propagation delay) but for anything higher on the
protocol stack you're probably not dealing with hard-and-fast
requirements so much as compromises between conflicting goals.
How secure should a protocol be? How scalable should a protocol be?
How flexible should a protocol be for different user communities or
operating environments? You usually can't answer these questions in
absolute terms. It's not like designing a bridge where you can say
that it must hold X number of metric tons static load and withstand a
wind of Y km/hr. That's not to say that you never nail down any
requirements of a protocol design, but the bulk of what must be
understood prior to the design phase is rarely so neat and tidy.
need problem definition documents and design goal documents from the
early phases of the process
Yes, absolutely. That's what a requirements document is supposed to be.
The problem is that within IETF when we try to talk of "requirements
documents", people look at the word "requirement" and think of them
something that, once established, dictates the protocol design. So
they try to define the requirements in such a way as to produce the
design they want to use. That's backwards. What needs to be done
instead is to develop a shared understanding of the design tradeoffs
within the working group. The word "requirements" gets in the way of
doing that.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf