Re: Fwd: RFC statistics and perspectives

[Geoff Huston <gih@telstra.net>]

At 04:45 PM 24/07/2003 -0400, Leslie Daigle wrote:
>I also think it would be important to circulate a draft
>reply to the IESG for input.


Here's a draft response - I'd like to send by the end of this week, so if you have
comments please respond by then.


thanks,

   Geoff

--------------------

Phil ,

Thank you for your note

As you are aware, RFC2026 describes the lifecycle of a Standards Track RFC
document within a number of "maturity Levels", namely  Proposed Standard,
Draft Standard, Internet Standard.

There are, at present, 61 published Internet Standards, 103 published
Draft Standards and 943 published Proposed Standards.

The pragmatic observation is that the Internet operates largely on
Proposed Standards, and it would be an ill-advised restriction from a pu
rely pragmatic perspective to restrict one's view of Internet technology
to be one that is strictly limited to those technologies described by
Internet Standards, or even Internet and Draft standards.

While a strict interpretation of your observation, that Proposed Standards
and Draft Standards are subject to change, is correct, it is necessary to
understand the nature of the amendments to the standard specification
in each of these maturity transitions.


As RFC 2026 states in Section 4.1.1 regarding Proposed Standards:

  "Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified, deploying
   implementations of such standards into a disruption-sensitive
   environment is not recommended."


Draft Standards are considered to be stable specification. Again quoting
from RFC 2026, Section 4.1.2:

  "A Draft Standard must be well-understood and known to be quite
   stable, both in its semantics and as a basis for developing an
   implementation.  A Draft Standard may still require additional or
   more widespread field experience, since it is possible for
   implementations based on Draft Standard specifications to demonstrate
   unforeseen behavior when subjected to large-scale use in production
   environments.

   A Draft Standard is normally considered to be a final specification,
   and changes are likely to be made only to solve specific problems
   encountered.  In most circumstances, it is reasonable for vendors to
   deploy implementations of Draft Standards into a disruption sensitive
   environment."



The transition to an Internet Standards is based more on deployment
experience than further refinement of the specification itself. Again
referring to RFC 2026, Section 4.1.3

  "A specification for which significant implementation and successful
   operational experience has been obtained may be elevated to the
   Internet Standard level.  An Internet Standard (which may simply be
   referred to as a Standard) is characterized by a high degree of
   technical maturity and by a generally held belief that the specified
   protocol or service provides significant benefit to the Internet
   community."
   
   
Your note advances the view that "any implementation short of what is in
the final version might be considered proprietary". This appears to be an
incorrect characterization of Proposed and Draft Standard specifications,
in that such specifications are classified at this maturity level due in
no small part to an observed lack of experience in assurance of
interoperability of implementations based on the specification, rather
than in response to any particular proprietorial claims that may be made
regarding the technology, or any particular known level of instability in the
implementation or specification.

It is true to observe that implementations that correctly implement the
entirety of an Internet Standard have a very high degree of assurance of
interoperability with other implementations of the same specification.
However it is also the case that implementations based on Draft Standards
have demonstrated some reasonable level of assurance of interoperability
of independant implementations of the specification. Proposed Standards
have been subject to IETF peer review and there is a high level of
confidence that the specification is robust and useful, but the caveats
described above with respect to Proposed Standards hold, and early
implementations correctly based on such specifications may not correctly
interoperate under all forms of deployment environments and conditions.

I trust this answers your query,

 Regards,
 
     Geoff Huston
      Executive Director, IAB



-----

From: "Hasse, Phillip R HQISEC/Veridian IT Services" <Phillip.Hasse@HQISEC.ARMY.MIL>
To: execd@iab.org
Subject: RFC statistics and perspectives
Date: Thu, 17 Jul 2003 13:05:50 -0700
X-Mailer: Internet Mail Service (5.5.2656.59)

Gentlemen,

I am writing this to you in hopes that you will be able to assist in
helping the DoD gain a proper perspective in mandating RFCs. I am
attempting to convince some very high level decision makers within the DoD
of what I believe is a realistic perspective on the mandating of RFCs.

The DoD has been trying for many years to evolve to a more supportable and
interoperable infrastructure. High level policy and architecture documents
will attest to this intent. I have recently been made aware that in some
instances "proposed" RFCs are being mandated in addition to "draft" RFCs.

I have been trying to make the point that only a final RFC can really be
considered a standard, and that any implementation short of what is in the
final version might be considered proprietary. I know that this will
depend on the extent of changes made. The degree to which a vendor can
adapt to the final version and the level of effort may vary depending on
whether it is hardware or software. I also think that interoperability may
not be assured with anything less than the standard.

I am looking for two things that may help. Input to give them on that
perspective, if it is correct, and some statistics if they are available.
A percentage of proposed RFCs that never make it to draft, Number of draft
RFCs that never made final status, if that happens, and the range of time
from draft to final and average. I know that some RFCs spend a long time
in a draft stage before making it to final.

I know it is likely that your office may not be the one to address this
but I would greatly appreciate you forwarding this to the appropriate
party if that is the case. I am trying to ensure that these folks have a
good understanding of the time frames and potential risks. Any other
information you believe might be appropriate to mention would be great.

Respectfully

Phil Hasse