Subject: Use cases for standards

From: "Bob Jueneman" <[email-masked]>
Date: Fri, 09 Nov 2001 09:19:42 -0700

Peter, the inclusion of a rationale would certainly be helpful, and probably ought to be mandatory for every RFC, just for the reasons you cite.  Too many RFCs read like formal mathematical proofs. They include the QED, but not the steps that led up to that conclusion, or even why the proof is significant.

But I also strongly agree with Anders that we should require a clearly documented and PREVIOUSLY AGREED to set of use cases that are clear, reasonably economical (in the sense that two uses cases should have relatively little overlap, so that too many different ways of solving the same problem aren't required), and reasonably comprehensive (not too much is left uncovered), prior to beginning the development of a standard.  

Most importantly, and I believe this is one of the most significant failings of the IETF culture in general, the use case must be compelling in terms of a business case.  The days of "if we build it they will come" are over, as witness a whole bunch of dot-com ex-millionaires.

If the group cannot come to some consensus regarding a reasonable use case, then clearly there is no need to develop a standard to cover that functionality.

This rule alone would have prevented some of the more egregious cases of feature creep and the pet rock syndrome, where everyone has to have their particular favorite proprietary algorithm or capability treated as the equivalent of federal or de facto standard algorithms.  It makes the standards much too complex, and as a result interoperability suffers greatly, because each group decided on their own what subset of the standard was worth implementing.  

Examples in the S/MIME space in particular would include the multitudinous variations of key wrapping algorithm combinations, message digest algorithms, password-based encryption algorithms, etc., etc., most of which will never see the light of day and will never be able to interoperate with anyone.  That's not why S/MIME has so far failed to thrive, but the gratuitous complexity certainly doesn't help -- busy developers and their management simply tune out and refuse to give serious consideration to the group's efforts after a while, if the complexity doesn't help the bottom line.

Bob

>>> Peter Gutmann <[email-masked]> 11/08/01 04:23PM >>>

"Ryan Hurst" <[email-masked]> writes:

>I would certainly advocate that we add a requirement that there is use case
>documentation included with all of these technology drafts.

What about requiring that drafts include a rationale, as the IEEE has always
done?  This is slightly different to what you're proposing, but would help in
two ways:

1. Authors would be forced to explain what they're doing, which would help
   clarify the thinking behind some of the stuff in PKIX drafs (and reduce the
   "WTF??!" factor experienced in reading some of them).

2. Readers wouldn't have to rely on guesswork so much, enhancing
   interoperability.

(It should be noted that no-one's actually prevented from including a
 rationale, it's just not usually done.  I've included a rationale for each
 decision in my drafts, which hopefully helps clarify things not explicitly
 mentioned in all the MUST/SHOULD/whatever text).

Peter.