Internet DRAFT - draft-ietf-newtrk-promotion

draft-ietf-newtrk-promotion







Network Working Group                                         J. Klensin
Internet-Draft
Expires: August 24, 2006                                      S. Dawkins
                                                  Futurewei Technologies
                                                       February 20, 2006


    Cleaning the Attic II: Promoting Marketplace-approved Standards
                  draft-ietf-newtrk-promotion-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 24, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Historically, Internet Standards have been characterized by three
   primary criteria: the specifications are stable, implementations of
   them have been demonstrated to be interoperable, and they have
   achieved sufficient deployment to be considered useful.  The IETF has
   developed specific rules for determining whether those criteria have
   been met, but the rules and their implementation have sometimes not
   adequately reflected those underlying criteria.  The result has been



Klensin & Dawkins        Expires August 24, 2006                [Page 1]

Internet-Draft       Promoting Marketplace Standards       February 2006


   that the application of the rules has not resulted in STDs for all
   protocols that meet the underlying criteria.  This document proposes
   a process experiment to reclassify standards-track documents whose
   interoperability and utility have been demonstrated by the fact of
   deployment and use in products being used by Internet users.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Documentation of Known Issues  . . . . . . . . . . . . . . . .  4
   3.  Definition of the Alternate Approval Path  . . . . . . . . . .  4
     3.1.  Enabling Document  . . . . . . . . . . . . . . . . . . . .  5
     3.2.  Review, Processing, and Approval . . . . . . . . . . . . .  6
       3.2.1.  Last Call Procedure  . . . . . . . . . . . . . . . . .  6
       3.2.2.  Preservation of Intent . . . . . . . . . . . . . . . .  7
   4.  The Experiment Itself  . . . . . . . . . . . . . . . . . . . .  7
     4.1.  IESG Workload  . . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Approval Process for this Experiment . . . . . . . . . . .  8
     4.3.  Discussion of Experimental Issues  . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     6.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 11

























Klensin & Dawkins        Expires August 24, 2006                [Page 2]

Internet-Draft       Promoting Marketplace Standards       February 2006


1.  Introduction

   Historically, Internet Standards have been characterized by three
   primary criteria:
   o  the specifications are stable,
   o  implementations of them have been demonstrated to be
      interoperable, and
   o  the implementations have achieved sufficient deployment to be
      considered useful (historically, "useful" has been judged by
      decisions to implement and use the protocol, not by the subjective
      judgment, taste, or preferences of some group).

   The IETF has developed specific rules for determining whether those
   criteria have been met.  They include the rules in [RFC2026] for each
   maturity level as well as provisions for regular review and timeouts
   of Proposed and Draft Standards.  But those rules and procedures have
   tended to become substitutes for the criteria themselves:
   specifications that are widely deployed and quite mature have not
   been advanced because of the particular rules that have been
   established for their advancement and people's responses to those
   rules.

   Following in the footsteps of the recent process to reclassify
   obviously obsolete standards (see [decruft]), this document proposes
   a process experiment [RFC3933] to reclassify standards-track
   documents whose interoperability and utility have been demonstrated
   by the fact of deployment and use in products being used by Internet
   users.  The experiment is intended as an alternate path to the one
   specified in RFC 2026, not a replacement for it, and is applicable
   only if a number of fairly stringent criteria are met.  For these
   documents, the experiment also modifies the details of the
   "downreferencing" procedure specified in [RFC3967] to permit
   substitution of explicit comments in the enabling document.

   While the mechanism proposed here is fairly formal (although not as
   formal as that called for in RFC 2026), it is worth noting that many
   documents developed before the IETF came into being, or in the IETF's
   early days, were classified as Internet Standards by informal
   processes that focused more on the above criteria than on specific
   rules about documents and procedures such as moving through clear
   "Proposed" and "Draft Standard" stages.

   There is a clear trade-off between being practical about solving
   current issues versus being dogmatic about the ideal policy one might
   prefer in an ideal world.  For protocols that have been widely
   deployed and proven useful via that deployment, the experiment
   proposed here is intended to shift the balance implied in that trade-
   off toward the practical.



Klensin & Dawkins        Expires August 24, 2006                [Page 3]

Internet-Draft       Promoting Marketplace Standards       February 2006


2.  Documentation of Known Issues

   Clearly, some of the specifications that qualify under the criteria
   outlined above would not qualify, even for Proposed Standard, under
   rules in use today.  They lack now-required RFC sections, extensive
   analysis of security and internationalization issues, and so on.
   However, for specifications that are appropriate for consideration
   under this process described here, the marketplace has decided that
   those issues are not critical.  That marketplace decision should
   properly take precedence over determinations made solely inside the
   IETF unless there is IETF community consensus that the specification
   and its implementations poses an actual and substantial danger (not
   merely a theoretical risk or a preference for a different model).

   If it is the consensus of the IETF community, as determined by the
   IESG using the usual mechanisms, that there are issues with the
   specification, or if the criteria applicable to RFCs moving along the
   conventional (i.e., RFC 2026) path are not met or now-required
   sections do not appear, those issues may be noted in a section of the
   enabling document (see Section 3.1) with the title of "Outstanding
   Issues".  That section might note, for example, that insufficient
   security analysis has been done, that the protocol is not properly
   internationalized, that some parts of the protocol have been better
   tested and more widely deployed than others, that the protocol has
   typically been deployed at "less than Internet scale", and so on.
   However, if the protocol is in use and has been significantly
   deployed, the intent of this effort is to document those issues and
   move on, rather than to artificially hold it at a maturity level more
   appropriate to specifications that have not yet been implemented or
   deployed.


3.  Definition of the Alternate Approval Path

   Any member (or group of members) of the IETF community (identified as
   "the proposer" below) may propose that a protocol specification be
   reclassified as an Internet Standard if the following minimum
   criteria are met.

   1.  The RFC documenting the specification, or the last-published RFC
       if there are more than one, was published at least three years
       earlier.
   2.  There is sufficient evidence of implementation, adoption, and use
       to make interoperability of the protocol and marketplace interest
       obvious.
   3.  The proposer is willing to generate an "enabling document" as
       described below.




Klensin & Dawkins        Expires August 24, 2006                [Page 4]

Internet-Draft       Promoting Marketplace Standards       February 2006


   Once an enabling document is generated, it will be submitted to the
   IAD.  The IESG will initiate a review process as described below.

   [[anchor3: Note in Draft: The experiment proposed here is an
   administrative procedure for upgrading documents.  While IESG review
   of a Last Call is a necessary part of the process, as described
   below, there is no requirement for a pre-Last-Call AD or IESG review
   of the enabling document(s).]]

3.1.  Enabling Document

   A proposal to advance a specification to Internet Standard under the
   model described here is made in the form of an "enabling document".
   That enabling document will be an Internet-Draft suitable for
   eventual publication as an RFC.  It MUST supply the information
   required below.  It may either reference one or more existing RFCs
   that will make up the Standard, or MAY be a new document that is
   intended to obsolete the relevant older ones.

   If a new document is developed, it must reflect the spirit and intent
   of the experiment.  Specifically, it may not introduce features that
   are not described in the original RFC(s) unless it clearly shows that
   they are as widely implemented as the original specification and have
   been implemented for at least three years.  In addition, the
   description of those features must derive from text that can be shown
   to have been tested by independent implementations and deployment,
   even if it was not previously published in the RFC series.

   Enabling documents must contain

   1.  A discussion of deployment of the specification adequate to
       demonstrate that interoperable implementations exist and have
       been deployed in a reasonable variety of networks.
   2.  A discussion of whether or not all features of the specification
       are believed to be demonstrated by the deployed implementations.
       Features that may be less deployed and tested than others should
       be identified to the extent reasonably possible.
   3.  A discussion of how the experience with the specification relates
       to current requirements for standards-track advancement of
       protocols that are less obviously mature.

   Except for the first, the intent of these sections is not to require
   new analysis or developments, but merely to document whatever the
   current status actually is.  As a crude example, statements such as
   "While no extensive internationalization analysis of this protocol
   has been performed and it therefore cannot be presumed to work with
   non-ASCII characters", or "While no extensive security analysis of
   this protocol has ever been performed and documented and hence some



Klensin & Dawkins        Expires August 24, 2006                [Page 5]

Internet-Draft       Promoting Marketplace Standards       February 2006


   caution should be used, no significant problems have appeared so far
   in actual practice" or "The security analysis of this protocol has
   not been reviewed or updated since 1991" would be considered
   acceptable in an enabling document.  By contrast, were they to appear
   in a document moving along the RFC 2026 Standards Track, we presume
   that the actual analysis and potentially protocol changes would be
   required before approval.

3.2.  Review, Processing, and Approval

   From the standpoint of document processing, enabling documents are,
   with the exceptions noted here, ordinary Internet Drafts submitted to
   the IESG for standards-track processing.  They are subject to a two
   or four-week Last Call depending on whether they originate from WGs
   or from a Proposer as an individual submission.

   There are two important differences, one of procedure and the other
   of principle.

3.2.1.  Last Call Procedure

   As mentioned above, there is no pre-Last Call AD or IESG review of
   enabling documents.  When an enabling document is ready, and has been
   posted as an I-D, the proposer may request that an IETF Last Call be
   initiated by request to the IESG Secretary or other individual
   designated by the IESG and announced to the community.  The person
   receiving the enabling document will cause the completeness of the
   enabling document to be checked and will verify that the three-year
   requirement has been met, then the Secretariat will issue the IETF
   Last Call.

   When the Last Call completes, the IESG will evaluate community
   consensus about the enabling document and promotion of the relevant
   specifications.  That evaluation will follow the intent of this
   document (see below), i.e., the imposition of additional technical,
   procedural, or other requirements other than documentation of
   deployment and status information is considered inappropriate.  The
   assumption of both the Last Call and IESG consensus review is that
   any protocol specification that has been around for several years,
   that has been deployed, and for which serious problem have not
   appeared in actual practice "in the wild" should be promoted to
   Internet Standard.  Other decisions or actions require either a
   demonstration that the claims made in the enabling document are not
   correct or strong community consensus that the protocol should not be
   promoted to Internet Standard despite wide deployment.






Klensin & Dawkins        Expires August 24, 2006                [Page 6]

Internet-Draft       Promoting Marketplace Standards       February 2006


3.2.2.  Preservation of Intent

   The procedure, and procedural experiment, proposed here is
   deliberately fragile.  If the IETF community generally, and the IESG
   in particular, are not, in practice, willing to recognize the
   criteria and principles outlined at the beginning of this document
   and conclude that the marketplace makes decisions about protocol and
   specification quality that are less stringent than we might impose
   according to our normal procedures, then the experiment will fail
   (if, indeed, it is initiated).

   The procedure remains fragile even if the principles are accepted.
   If nit-picking during Last Call is confused with legitimate concerns
   about a protocol, or if IESG members impose requirements above and
   beyond the clear intent of this document to keep such requirements
   minimal, then the procedure will rapidly deteriorate into
   uselessness, if only by discouraging potential proposers from writing
   enabling documents.  Extended arguments about how much deployment is
   sufficient, or details of document quality, would be likely to have
   similar effects.

   Experimental success ultimately requires that the community, as a
   community, decide that identification and promotion of widely-
   deployed protocols, in recognition of marketplace decisions, is worth
   doing.


4.  The Experiment Itself

4.1.  IESG Workload

   To the extent to which this experiment encourages efforts to advance
   documents that otherwise would continue to rest in the purgatory of
   resting indefinitely in Proposed (or even Draft) Standard while RFC
   2026 insists that they be re-identified as historic and abandoned,
   the effort will increase the number of specifications the IESG needs
   to evaluate and hence IESG workload.  On the other hand, the load on
   the IESG should be considerably less that for a protocol proposal
   advancing along the normal RFC 2026 path: there is no evaluation of
   protocol quality, no IESG evaluation of document quality, and no need
   to carefully review the description of the protocol and its possible
   impact: each of those normal tasks would constitute second-guessing a
   decision that has already been made in the marketplace.  The workload
   should be equivalent to, or less than, that encountered in the
   "decruft" process and leads to a more productive end --
   identification of successful protocols rather than formally retiring
   those to which no one has paid attention in recent years.  If the
   IESG, and the community, are not willing to take on this level of



Klensin & Dawkins        Expires August 24, 2006                [Page 7]

Internet-Draft       Promoting Marketplace Standards       February 2006


   effort, then the IETF standards process is in great difficulty
   indeed.

4.2.  Approval Process for this Experiment

   To be initiated, this experiment must be approved according to the
   model in RFC 3933.  The IESG and community should note that it
   effectively makes a significant change to RFC 2026's definitions of
   maturity levels and the procedures for attaining them by providing a
   fast-track procedure for protocols that have already proven
   themselves by marketplace-based criteria.  This experiment should not
   be approved if the community believes that such criteria, and
   marketplace decisions, are irrelevant or that the IETF community in
   general and the IESG in particular have a level of wisdom about the
   quality of IETF-developed protocols that outweighs any possible
   marketplace action or deployment.  It should be noted in that regard
   that the procedure described here is applicable only to protocol
   documents that the IETF or its predecessors, through its normal
   processes, have already put on the standards track.  In particular,
   it cannot be used to turn something that has gained marketplace
   deployment by marketing efforts alone, without IETF involvement and
   approval, into an Internet Standard.

4.3.  Discussion of Experimental Issues

   It is recommended that the experiment run for one year.  During that
   period, it will be important to track several measurements of success
   and utility.  Those include the number of documents that are actually
   proposed for advancement, the number of attempts that are successful
   and unsuccessful, and whether there is any pattern to the Proposers
   of successful and unsuccessful enabling documents.  We would
   encourage the IESG to also be sensitive to the time investment that
   is required, both in absolute terms and in comparison to reviews of
   documents being advanced using the normal procedure.  We would also
   encourage the community as a whole to track conformance to the intent
   of the issues raised in Section 3.2.2.

   If a Proposer generates three or more consecutive enabling documents
   that fail to gain community consensus, the IESG may adopt
   restrictions on additional submissions from that proposer, require
   endorsements prior to submission by that proposer, or, in their
   discretion, adopt other measures to ameliorate either denial of
   service attacks (intentional or unintentional) or outbreaks of
   stupidity.


5.  Security Considerations




Klensin & Dawkins        Expires August 24, 2006                [Page 8]

Internet-Draft       Promoting Marketplace Standards       February 2006


   This document addresses IETF procedures and hence does not raise new
   security issues of its own.  However, it is explicitly intended to
   permit protocol specification documents to advance to Internet
   Standard without the level of security analysis typically required
   for new documents.  The enabling document is expected to warn the
   reader of actual security risks and problems that have been identifed
   in practice and to note the level of analysis that has been done, but
   not to go any further.


6.  References

6.1.  Normative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC3933]  Klensin, J. and S. Dawkins, "A Model for IETF Process
              Experiments", BCP 93, RFC 3933, November 2004.

   [RFC3967]  Bush, R. and T. Narten, "Clarifying when Standards Track
              Documents may Refer Normatively to Documents at a Lower
              Level", BCP 97, RFC 3967, December 2004.

6.2.  Informative References

   [decruft]  Lear, E. and H. Alvestrand, "Getting rid of the cruft:
              Report from an experiment in identifying and reclassifying
              obsolete standards documents",
              draft-ietf-newtrk-decruft-experiment-03 (work in
              progress), January 2006.

              This document has been approved as a BCP and is awaiting
              publication.

















Klensin & Dawkins        Expires August 24, 2006                [Page 9]

Internet-Draft       Promoting Marketplace Standards       February 2006


Authors' Addresses

   John C Klensin
   1770 Massachusetts Ave, #322
   Cambridge, MA  02140
   USA

   Phone: +1 617 491 5735
   Email: john-ietf@jck.com


   Spencer Dawkins
   Futurewei Technologies
   1547 Rivercrest Blvd.
   Allen, TX  75002
   USA

   Phone: +1 214 755 3870
   Email: spencer@mcsr-labs.org
































Klensin & Dawkins        Expires August 24, 2006               [Page 10]

Internet-Draft       Promoting Marketplace Standards       February 2006


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Klensin & Dawkins        Expires August 24, 2006               [Page 11]