One document matched: draft-bradner-restore-proposed-00.txt

Network Working Group                                         J. Klensin
Internet-Draft
Intended status: Informational                                S. Bradner
Expires: August 2, 2011                               Harvard University
                                                        January 29, 2011


            Restoring Proposed Standard to Its Intended Use
                 draft-bradner-restore-proposed-00.txt

Abstract

   Restore the very low bar for Proposed Standard described in RFC 2026
   (BCP 9)

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on August 2, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.





Klensin & Bradner        Expires August 2, 2011                 [Page 1]

Internet-Draft          Restore Proposed Standard           January 2011


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Discussion List . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Remedy  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Schedule  . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6







































Klensin & Bradner        Expires August 2, 2011                 [Page 2]

Internet-Draft          Restore Proposed Standard           January 2011


1.  Introduction

   Few IETF technologies progress beyond Proposed Standard.  This has
   been identified as a problem for quite a while [RFC3774].  A number
   of proposals have been made to fix this problem.  Some of the
   proposals would change the number of stages in the IETF standards
   process and/or reduce the requirements to progress a technology along
   the standards track.  But there is no reason to believe that any of
   these proposals would actually result in a significant change to the
   percentage of authors or working groups undertaking the effort to
   progress their documents.

   On the other hand there is reason to believe that the current
   stringent review given by the IESG to documents proposed for
   publication as Proposed Standard RFCs at contributes to the
   reluctance of authors and working groups working on progressing their
   documents.  The current level of review means that most implementers
   consider Proposed Standard documents as "finished" and ready for
   implementation and deployment.  If a technology is widely deployed
   there is, naturally, less incentive to continue to work on it, even
   to update the specification to reflect changes made during
   implementation.  Instead the incentive is to move on to other
   development efforts.  It should also be noted that, in many cases,
   Internet Drafts have taken on the role that the IETF Standards
   Process reserved for Proposed Standard starting with the first time
   that the process was written down [RFC1310].  Internet Drafts are
   implemented on the basis of working drafts and the technology is
   deployed, sometimes into production networks, due, in part, to the
   delay introduced in the IESG review process for Proposed Standard
   documents.

   Reducing the number of stages in the standards track or changing the
   requirements for advancement will likely have little or no effect as
   long as the IESG continues its current level of review for Proposed
   Standard.  Thus, restoring the original IETF concept of the
   applicability and completeness of Proposed Standards is a
   prerequisite to considering any of these proposals.

   RFC 2026 (BCP 9), Section 4.1 [RFC2026] intended a very low bar for
   Proposed Standard, essentially that the text be clear enough that the
   community could examine the protocol, develop trial implementations,
   and begin testing both the protocol and the specification text.  The
   relevant text in 2026 says specifically:

      A Proposed Standard specification is generally stable, has
      resolved known design choices, is believed to be well-understood,
      has received significant community review, and appears to enjoy
      enough community interest to be considered valuable.  However,



Klensin & Bradner        Expires August 2, 2011                 [Page 3]

Internet-Draft          Restore Proposed Standard           January 2011


      further experience might result in a change or even retraction of
      the specification before it advances.

      Usually, neither implementation nor operational experience is
      required for the designation of a specification as a Proposed
      Standard.
      [...]

      A Proposed Standard should have no known technical omissions with
      respect to the requirements placed upon it.
      [...]

   In the years subsequent to the publication of RFC 2026, the actual
   IESG review for Proposed Standard has evolved to require a very high
   quality level of protocol completeness and specification and
   editorial quality.  It is common for working groups, and then those
   groups in conjunction with various ADs, to spend weeks or months
   refining small editorial or technical points, requiring extensive
   security and other analyses, and so on, even though the underlying
   specification is clear enough for implementation and testing and
   there are no obvious technical defects.  The length and difficulty of
   that process then contributes to a vicious cycle.  As the bar to
   publishing a Proposed Standards becomes higher, the combination of
   market pressures and WG exhaustion results in fewer documents
   advancing beyond Proposed Standard and more of the Internet running
   on Proposed Standards.  Conversely, as more of the Internet runs on
   Proposed Standards and fewer documents advance from that level, the
   IESG and the community perceive pressure to achieve perfection in
   Proposed Standard documents, leading to a higher bar to publication.

   That situation helps no one and hurts the Internet and the IETF and
   its reputation.


2.  Discussion List

   [[anchor2: RFC Editor: Please remove this section.]]

   Until and unless the General Area AD designates another location,
   this proposal should be discussed on the general IETF mailing list.


3.  Remedy

   No changes are required to RFC 2026 or other established procedural
   documents to break the cycle described above and restore the
   threshold for publishing a specification at Proposed Standard to its
   intended level.  However, because the IESG perceives community



Klensin & Bradner        Expires August 2, 2011                 [Page 4]

Internet-Draft          Restore Proposed Standard           January 2011


   support for a high level of specification and editorial quality in
   Proposed Standards, some reasonable level of community consensus and
   a target date may be needed to accomplish the goal of faster and
   lighter weight Proposed Standard processing (consistent with RFC
   2026).

   This document is intended to act as a focus for that consensus-
   building discussion.

   Nothing in this document alters the IESG's authority, as specified in
   RFC 2026, to impose additional requirements, particularly
   demonstration implementation or testing requirements, in exceptional
   circumstances on specifications intended as Proposed Standards.
   However, the intent of this document is to restore the use of such
   additional requirements to truly exceptional circumstances.


4.  Schedule

   Upon the approval of this document, the IESG will designate a target
   date, not more than 90 days in the future, after which documents
   entering the standards track will be processed strictly as intended
   in RFC 2026.  In other words, unless exceptional circumstances apply,
   the criteria for approval of a Proposed Standard will be stricted
   those outlined in RFC 2026 (and quoted in Section 1 above).

   The IESG is authorized and encouraged, but not required, to revise
   the boilerplate text for newly-published Proposed Standard
   specifications to indicate that they do not indicate IETF endorsement
   of specification quality or desirability, only that the
   specifications are considered adequate for study, implementation, and
   testing.  Similarly, the IESG may specify boilerplate for Security
   Considerations and other required RFC sections that notes that those
   sections in Proposed Standards should not be expected to be complete
   and comprehensive.


5.  IANA Considerations

   [[anchor5: RFC Editor: Please remove this section before
   publication.]]

   This memo includes no requests to or actions for IANA.


6.  Security Considerations

   This document should, if effective, lead to Proposed Standards that



Klensin & Bradner        Expires August 2, 2011                 [Page 5]

Internet-Draft          Restore Proposed Standard           January 2011


   are published sooner and that are much more clear about their status
   and the status of whatever evaluations are performed.  Other than the
   side-effects of that change, this document should have no
   consequences for the security of the Internet.


7.  References

7.1.  Normative References

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

7.2.  Informative References

   [RFC1310]  Chapin, A., "The Internet Standards Process", RFC 1310,
              March 1992.

   [RFC3774]  Davies, E., "IETF Problem Statement", RFC 3774, May 2004.


Authors' Addresses

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

   Phone: +1 617 245 1457
   Email: john-ietf@jck.com


   Scott Bradner
   Harvard University
   29 Oxford St
   Cambridge, MA  02138
   USA

   Phone: +1 617 495 3864
   Email: sob@harvard.edu











Klensin & Bradner        Expires August 2, 2011                 [Page 6]