Subject: RE: [newtrk] Key words to Indicate Requirement Levels

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Mon, 3 May 2004 16:48:42 +0200

> > This might focus our discussion of RFC 2119 keywords,
> > too: what else, in the IETF process, could they be used
> > for, anyway?
> 
> seems to me that these keywords should be used sparingly -
> not everywhere they could possibly be used.  in the proper 
> context they are quite useful.  over-use would dilute
> their effectiveness.

We're in total agreement here. The question is what should
be done to prevent over-use, and promote "proper" use, as
today there is too much over-use.

> > Would it be unreasonable to add a NEW set of keywords,
> > for use in requirements documents (which lay out constraints
> > on technical specifications)?
> 
> it's unreasonable to write requirements documents.  design 
> goals good, requirements documents bad.

As an editor of a few requirements documents, I actually tend
to agree with you. In most cases, they turn out to be design
goals, rather than requirements, and should probably have a
different label then. If we continue to publish these kind
of documents as RFC's, we should have better guidelines on
how to write them and what actually makes sense to write
(e.g. a BCP not to try to put down unrealistic or
contradicting requirements). We should not waste too many
cycles on these documents, and better guidance for both
WG's and editors would help in that regard.

/L-E
 
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Mon, 10 May 2004 11:38:11 +0200

> > The reason I like Larry's definitions above is that phrases 
> > like "general agreement" are a good match for a goals document,
> > and a bad match for an interoperability specification.
> 
> Larry's definitions rate the "importance" of a feature. Their actual
> value for a goals document user is unclear to me because it is unclear
> how goal implementations (i.e., candidate protocol specs) would be
> compared with each other. Is it better to satisfy (90% of CRITICAL and
> 90% of IMPORTANT features) than to satisfy (95% if CRITICAL and 10% of
> IMPORTANT features)? Will violation of any CRITICAL feature result in
> rejection of protocol candidate? If there are now answers to such
> questions, then why fool ourselves with an importance rating??

IMHO, writing goals documents is nothing we do to define how to rate
"candidate protocols", but to get an agreement on the actual needs of
the protocols WE ARE DESIGNING. Often there are protocol proposals,
and whether to use features or parts of those proposals in our
protocols might depend on the goals. However, I do not believe in
creating more formal ways of handling such a process, as each case
is specific and common sense and technical argumentation is much
more proper tools for that than strict rules and formalism.

/L-E

.

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Mon, 10 May 2004 11:45:49 +0200

> > > strongly disagree.  the point of design goals is really to reach a
> > > shared definition of the problem and of the bounds of the problem,
> > > not to impose formal constraints on the solution.
> > 
> > We cannot reach [meaningful/true] shared definition of the
> > problem/bounds without some level of formalism.  
> 
> I've seen too many groups get bogged down in trying to argue
> MUST vs. SHOULD on "requirements"  where they didn't even understand
> what they were talking about.  I've also seen too many specifications
> get submitted for Proposed where 2119 keywords were mis-used or
> over-used - for instance, capitalizing every use of "should" even
> when the meaning had nothing to do with compliance with the
> specification. 

I fully agree with Keith here. These are the reasons why I think
we should do something, and I also agree with Keith that it does
probably NOT mean we should change the 2119 definitions, but
rather give better guidelines for how to use 2119.

> I've become firmly convinced that trying to coerce
> early problem definitions into "requirements" with MUSTs and SHOULDs
> is counterproductive simply because it's trying to nail things down
> long before the concepts - or their implications for the protocol
> design - are well-understood. 

Having some guidelines for how to write "pre protocol design"
documents could also be useful, i.e. that trying to nail down
requirements before understanding the actual problems, base
concepts, and how these will affect the design, is a bad idea.

/L-E
.