[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: RFC statistics and perspectives
Fine.
jak
----- Original Message -----
From: "Geoff Huston" <gih@telstra.net>
To: "Leslie Daigle" <leslie@thinkingcat.com>
Cc: <iab@ietf.org>; <iesg@ietf.org>
Sent: Wednesday, August 13, 2003 5:01 PM
Subject: Re: Fwd: RFC statistics and perspectives
> 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
>
>
>
>
>
>