From: "Jacob Palme" <jpalme(_at_)dsv(_dot_)su(_dot_)se>
Sent: Wednesday, July 31, 2002 11:49 AM
This message, which I got recently, shows how some people
react to what is happening around us. What is our responsibilities
as standards developers for allowing this to happen?
If, as a newcomer to this list, I may be so bold as to respond directly
to this question, my response is that there are definite responsibilities.
One of the concepts used in formal software methodologies is that of
a standard list of quality factors. My best example is the FURPS+
model, introduced by HP some years ago. FURPS stands for
Functionality, Usability, Reliability, Performance, and Scalability
(with the plus being added later since this list is obviously incomplete).
The principle is that any software development project must, in its
project documentation, address each of these issues, even if at times
the correct comment is "Not relevant."
As I start learning the IETF process, the only similar criterion that
stands out as being required is "implementability," i.e. it is a
requirement that implementations exist for protocol standards to
advance through the process.
I believe it is an obligation for standards developers and standards
bodies to have a reasonably robust list of such criteria. Security is
surely one of those criteria, and issues such as authentication,
avoiding denial of service attacks, etc. are standard subitems
of that criterion.
This certainly wasn't the case in the original 821/822. Indeed, some
may say that the ability to forge is a feature. However, for future
work, I wonder if it wouldn't make sense for the standards process
to say that "Security" is a required section for all protocol standards
documents to advance in the process.
Gary