Subject: RE: RFC 2119 applicability

From: Eric Burger <[email-masked]>
Date: Fri, 17 Jun 2005 18:56:41 -0400

As a relative newcomer to the IETF, with only 10 years of active
participation, here are my observations on the perennial 2119 discussion.

With respect to Informational documents that describe a protocol: it is
insane to say that a _protocol_ that is a _protocol_ but has the feature of
either (1) not of general Internet scope, (2) coming from another standards
body, or (3) is too controversial to get reasonable consensus but yet is too
necessary to ignore is *not* a _protocol_.

If we are talking about a protocol, use protocol definition language, like
RFC2119.

With respect to Informational documents that describe requirements: last
time I looked, a Requirements document states what the general problem to
solve is.  More importantly, from a work perspective, Requirements documents
state that the solution set MUST address some set of requirements, SHOULD
address another set of requirements, and MAY address yet another set of
requirements.

How many definitions of MUST, SHOULD, and MAY do we need?  Why is one not
enough?

My belief is the problem is that many people do not consider the reference
to RFC2119 as a pointer to the definitions for MUST, SHOULD, MAY,
RECOMMENDED, etc.  Rather, they take the reference to RFC2119 to be an
indicator that "this document describes an Internet Standards Track
Document."  In fact, it makes a good litmus test to determine who is an IETF
cognoscenti versus who is a neophyte.  After all, it takes the experience of
being flamed for putting a reference to RFC2119 in an Informational document
to learn that some people consider the reference to RFC2119 to have nothing
at all to do with the standard definitions of key terms.

LET US STOP THE MADNESS

I would offer a selection of two paths to follow.

Path 1: Use RFC2119 For the Standard Definitions of Key Words

Rationale: Makes for consistent interpretation of key words in documents.

Operation: Instead of using the presence or absence of a reference to
RFC2119 to indicate "Standards Track" or "Informational", respectively, we
put "Standards Track" or "Informational" on the document.

Implementation: I would suggest putting the legend "Standards Track" or
"Informational" in the upper left-hand corner of the first page of the
document.  Oh -- that is what RFC2026 requires.  I suppose no work need be
done, except to stop whining about references to RFC2119 in Informational
documents that need a standard definition of the terms MUST, SHOULD, MAY,
etc.

Path 2: Use RFC2119 As An Indicator of Document Status

Rationale: Many well-respected people have been saying for years that this
is what a reference to RFC2119 in a document means.  That assumes that there
is no expectation for anyone to attempt to implement protocols that are
documents in Informational RFC's.

Work to do: First, one needs to make the assumption that no one will
implement Informational drafts.  I would expect that no one implemented NFS
from the RFC specification or any of the ten MGCP RFCs.  [Yes, that was
sarcastic.]

Second, we need to change the title of RFC2119 to something more
descriptive, like "Document Placeholder to Indicate This Draft Will Be
Standards Track."  It is poor protocol design to overload messages and to
have implied actions.  It is much better to "Say What You Mean."

Third, we need to update RFC2026 to say that for Standards Track documents,
the author needs to indicate "Standards Track" in the upper left-hand corner
of the first page of the document *and*, in case that packet gets dropped,
include a redundant indicator by including a reference to RFC2119 in the
document.

IMHO, I would offer the first approach is much less work, intuitive, and
consistent...
 
--
- Eric

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Friday, May 27, 2005 4:37 AM
> To: [email-masked]
> Subject: RFC 2119 applicability [Re: [Fwd: I-D 
> ACTION:draft-iesg-info-exp-00.txt]]
> 
> I seriously, deeply, humbly ask people to change the subject 
> field when they change the subject.
> 
> IMHO there are no words in 2119 that forbid the 2119 
> terminology being used in non-standards track documents. 
> Whether it is worth the cost of updating the document to 
> provide more guidance is another question, which I would 
> propose that interested parties discuss with the original 
> author (volunteering to do the work is often helpful).
> 
>     Brian
> 
> Randy Presuhn wrote:
> > Hi -
> > 
> > I think there are cases where use of 2119 keywords is perfectly 
> > appropriate in non-standards track documents, and, on 
> occasion, even 
> > in requirements documents.  Yes, there is the potential for misuse, 
> > but that happens even in standards-track documents.
> > 
> > When an RFC 2119 SHOULD or MUST carries exactly the right 
> meaning, why 
> > use something else?
> > 
> > Randy

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 19 Jun 2005 08:22:01 +0200

Well written!

> documents that need a standard definition of the terms MUST, SHOULD, MAY,

Hear, hear!

(in case anyone is still in doubt... I agree)

---

From: Fred Baker <[email-masked]>
Date: Sun, 19 Jun 2005 00:05:53 -0700

except that we have already agreed that 2119 is used for both standards 
and non-standards documents, and that the most obvious use of 
requirements language is in requirements documents, which are rarely 
standards track.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 19 Jun 2005 21:18:16 +0200

That's OK. 2119 defines some words. As far as I can see, and as Eric and
Harald say, using those definitions is just fine in any category of
document that they are useful for. As a matter of fact, I've seen
citations of 2119 in specs from at least two other standards bodies.

    Brian