[ih] Re: Common Questions, RFC-compliant Architecture

[Bob Braden]

----- Begin Included Message -----

>From braden at ISI.EDU  Fri Sep  6 09:47:44 2002
From: Bob Braden <braden at ISI.EDU>
Date: Fri, 6 Sep 2002 16:47:40 GMT
To: ietf at ietf.org, Brian.Bisaillon at mbs.gov.on.ca
Subject: Re: Common Questions, RFC-compliant Architecture
Cc: braden at ISI.EDU
X-AntiVirus: scanned by AMaViS 0.2.1

Brian,

You asked:

  *> 
  *> Hello,
  *> 
  *> Has the IETF ever created an RFC to aid organizations with what standards are absolutely mandatory in terms of interoperability and what other standards are optional?
  *> 

Yes.  Here is some history.

In 1988, at the request of DARPA, the [original incarnation of the] IAB
asked the RFC editor Jon Postel to regularly publish a list of all
Internet protocols.  This list was first published in December 1988 as
RFC 1083, "IAB Official Protocol Standards".  If you search the RFC
index for "official protocol standards", you will find that it has been
republished 29 time since, although the title shifted at some point to
"Internet Official Protocol Standards."  The most current list is now
available in the RFC Editor web site at
www.rfc-editor.org/rfcxx00.html.

Jon Postel's Official Protocol Standards lists always included an
attribute called "Status", which is the "requirement level".  I
reproduce Jon's words at the end; always the Computer Scientist, Jon
loved precise specifications.

However, as Jon noted in the more recent documents, "The status or
requirement level is difficult to portray in a one word label.  These
status labels should be considered only as an indication, and a further
description, or applicability statement, should be consulted."  In
fact, it became increasingly clear over the years that applicability is
a very complex set of interrelationships.  Simple yes/no rules are
simply not useful (NOT EVEN to marketing types, and CERTAINLY not to
technical people.)   Interoperability issues are a LOT more complex
than this, and protocols are complex in general.  Protocols feel
no moral necessity to be simple in order to please CAOs or
CIOs; complexity is the nature of the beast.

If you glance at the Status field in RFC 2400, you will see that it is
really totally meaningless and probably misleading.  It was therefore
dropped from RFC2500 and succeeding versions of the Official Protocol
Standards.

When the IAB originally laid out the Internet standards process, it
recognized the category of RFCs called "applicability statements",
which are intended to define precisely what you ask for: "what
standards are absolutely mandatory in terms of interoperability and
what other standards are optional".  These documents would also
hopefully provide motivations and explanations to allow a technical
person to make mature judgments, but they would be limited to specific
protocol areas.  For example, RFCs 1122 and 1123 were applicability
statements for hosts and RFC 1812 for routers.  These were both
monumental tasks, and both are today hopelessly out of date.

BTW, the IAB's applicability statements were in part inspired by
what they saw as the inadequacy of the OSI profiling efforts that
were in progress at the time.

I personally agree with you that the Internet community would benefit
from putting more energy into writing and rewriting applicability
statements rather than energy into generating new protocols, but
unfortunately it is hard to find the motivation and funding for doing
the right thing in this case.

I think that your question really points to what should be done in the
future rather than how we got where we are, but it is useful to start
by understanding the history in the IETF (and before).

Bob Braden


Excerpt from Jon Postel's Official Protocol Standards documents:

   There are two independent categorization of protocols.  The first is
   the "maturity level" or STATE of standardization, one of "standard",
   "draft standard", "proposed standard", "experimental",
   "informational" or "historic".  The second is the "requirement level"
   or STATUS of this protocol, one of "required", "recommended",
   "elective", "limited use", or "not recommended".

   The status or requirement level is difficult to portray in a one word
   label.  These status labels should be considered only as an
   indication, and a further description, or applicability statement,
   should be consulted.

   When a protocol is advanced to proposed standard or draft standard,
   it is labeled with a current status.

   At any given time a protocol occupies a cell of the following matrix.
   Protocols are likely to be in cells in about the following
   proportions (indicated by the relative number of Xs).  A new protocol
   is most likely to start in the (proposed standard, elective) cell, or
   the (experimental, limited use) cell.

                             S T A T U S
                     Req   Rec   Ele   Lim   Not
                   +-----+-----+-----+-----+-----+
           Std     |  X  | XXX | XXX |     |     |
       S           +-----+-----+-----+-----+-----+
           Draft   |  X  |  X  | XXX |     |     |
       T           +-----+-----+-----+-----+-----+
           Prop    |     |  X  | XXX |     |     |
       A           +-----+-----+-----+-----+-----+
           Info    |     |     |     |     |     |
       T           +-----+-----+-----+-----+-----+
           Expr    |     |     |     | XXX |     |
       E           +-----+-----+-----+-----+-----+
           Hist    |     |     |     |     | XXX |
                   +-----+-----+-----+-----+-----+


----- End Included Message -----