Subject: RE: A question about requirements

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Tue, 23 Sep 2003 10:20:03 +0200

> >> As I watch discussions in some other groups, and am possibly
> >> approaching such an issue in my WG, I have started wondering
> >> about the force of requirements documents published as
> >> Informational.
> >>
> > <snip>
> >>
> >> yet fill them with words like MUST, MUST NOT, SHOULD etc...
> >
> > If the words are used as defined by 2119, I interpret them as
> > only intended for standards track documents. If used in e.g.
> > informational documents, I think the meaning of the words
> > should be defined within such documents.
> 
> repeated bone of contention when discussing documents in the
> IESG. I believe, and I think the IESG currently believes,
> that the uppercase words are a tool for making a specification
> clear; as such, it does not make sense to deny the tools for
> clarity to documents just because we are not making them
> IETF-approved standards track documents.
> 
> it makes perfect sense to claim that you implement an
> Informational protocol (people do that all the time); I think
> it's in the best interests of the Internet that those
> protocols' specifications be as clear as possible.

I agree with you when considering protocols published as
informational, i.e. "standards-track type" documents. However,
for non-protocols, e.g. "requirements", which was the origin
of this thread, I do not think the upper-case words can be
used based on 2119. 

But if the IESG thinks it is ok, I have no problem with that...=)

/L-E

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 23 Sep 2003 05:24:28 -0700 (PDT)

> But if the IESG thinks it is ok, I have no problem with that...=)

Here's an excerpt from RFC 2989:

1.1.  Requirements language

   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [RFC2119].

   Please note that the requirements specified in this document are to
   be used in evaluating protocol submissions.  As such, the
   requirements language refers to capabilities of these protocols; the
   protocol documents will specify whether these features are required,
   recommended, or optional.  For example, requiring that a protocol
   support confidentiality is NOT the same thing as requiring that all
   protocol traffic be encrypted.

   A protocol submission is not compliant if it fails to satisfy one or
   more of the MUST or MUST NOT requirements for the capabilities that
   it implements.  A protocol submission that satisfies all the MUST,
   MUST NOT, SHOULD and SHOULD NOT requirements for its capabilities is
   said to be "unconditionally compliant"; one that satisfies all the
   MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT
   requirements for its protocols is said to be "conditionally
   compliant."