Improving "Rough Consensus" with Running Code
draft-sheffer-running-code-00

Network Working Group                                         Y. Sheffer
Internet-Draft                                                  Porticor
Intended status: Experimental                           December 7, 2012
Expires: June 10, 2013

             Improving "Rough Consensus" with Running Code
                     draft-sheffer-running-code-00

Abstract

   This document proposes a simple-to-implement solution to the problem
   of rewarding Internet protocols that have been implemented over those
   that have not.  Rather than establishing an explicit process, we
   allow authors to publicize their implementation, which should enable
   working groups to treat relevant drafts preferentially.

   This solution is suggested for consideration as a process experiment.

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 June 10, 2013.

Copyright Notice

   Copyright (c) 2012 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

Sheffer                   Expires June 10, 2013                 [Page 1]
Internet-Draft                Running Code                 December 2012

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.    Introduction  . . . . . . . . . . . . . . . . . . . . . . . . 3
   1.1.  Conventions used in this document . . . . . . . . . . . . . . 3
   2.    The "Implementation Status" Section . . . . . . . . . . . . . 3
   3.    Benefits  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.    Process Experiment  . . . . . . . . . . . . . . . . . . . . . 4
   4.1.  Duration  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.2.  Summary Report  . . . . . . . . . . . . . . . . . . . . . . . 5
   4.3.  Success Criteria  . . . . . . . . . . . . . . . . . . . . . . 5
   5.    Implementation Status . . . . . . . . . . . . . . . . . . . . 5
   6.    Security Considerations . . . . . . . . . . . . . . . . . . . 5
   7.    IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
   8.    Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 6
   9.    References  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   9.1.  Normative References  . . . . . . . . . . . . . . . . . . . . 6
   9.2.  Informative References  . . . . . . . . . . . . . . . . . . . 6
         Author's Address  . . . . . . . . . . . . . . . . . . . . . . 6

Sheffer                   Expires June 10, 2013                 [Page 2]
Internet-Draft                Running Code                 December 2012

1.  Introduction

   Most IETF participants are familiar with the saying, "rough consensus
   and running code", and can identify with its pragmatic approach.
   However we are all aware of I-Ds that have gone through to
   publication with no implementation.  Some of them may never get
   implemented.

   It was recently proposed [I-D.farrell-ft] to fast-track Internet
   drafts that have associated code.  There are two issues with this
   proposal:

   o  It is unclear if the "fast track" mechanism improves the quality
      of the final RFC or rather detracts from it by reducing the amount
      of review.
   o  The fast-track mechanism can at best cut the overall time until an
      RFC is published by a month or two.  This is meager motivation for
      authors who can typically expect about a 2 year period from the
      initial version of the document until publication.

   Instead, we propose a simpler process, whereby draft authors can
   publicize the availability of running code.  It is up to the
   individual working groups to use this information as they see fit.

   We suggest that this proposal be adopted as a process experiment,
   within the lightweight framework of [RFC3933].

1.1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  The "Implementation Status" Section

   Each Internet Draft MAY contain a section entitled Implementation
   Status, located just before the Security Considerations.  This
   section, if it appears, should contain for each existing
   implementation of the draft:

   o  The implementation's name and/or a link to the implementation.
   o  A general description.
   o  The implementation's level of maturity: alpha, beta, production,
      or widely used.
   o  Coverage: how much of the proposed standard is implemented.

Sheffer                   Expires June 10, 2013                 [Page 3]
Internet-Draft                Running Code                 December 2012

   o  Licensing: whether the implementation is closed source, shareware,
      or open source.

   In addition, this section can contain information about the
   interoperability of any or all of the implementations.

   Since this information is necessarily time-dependent, the authors
   SHOULD remove this section when the I-D is published as an RFC.

   Another subsection that could be valuable (but could equally prove
   controversial) is an assertion of the IPR status of the
   implementation, e.g. whether it can be reused with no known
   encumbrance.

3.  Benefits

   Publishing the information about implementations provides the working
   group with several benefits:

   o  Participants are motivated to implement protocol proposals, which
      helps in discovering protocol flaws at an early stage.
   o  Other participants can use the software, to evaluate the
      usefulness of protocol features.
   o  WG members may choose to perform interoperability testing with
      known implementations, especially when they are publicly
      available.
   o  In the case of open source, people may want to study the code to
      better understand the protocol and its limitations.
   o  And lastly, some protocol features may be hard to understand, and
      for such features, the mere assurance that they can be implemented
      is beneficial.

   We do not specify here whether and to what degree working groups are
   expected to prefer proposals that have "running code" associated with
   them, over others that do not.

4.  Process Experiment

   The current proposal is a natural candidate for a process experiment,
   as described in [RFC3933].  This section defines the details of such
   an experiment.

4.1.  Duration

   Given the typical time to produce an RFC (see [stats]), we propose a
   duration of 18 months for the experiment.

Sheffer                   Expires June 10, 2013                 [Page 4]
Internet-Draft                Running Code                 December 2012

4.2.  Summary Report

   The author will summarize the results of the experiment at the end of
   the period.  If nothing happens (no I-Ds or only a handful include an
   Implementation Status), an email to the IETF list is sufficient.
   This would obviously constitute a failure of the experiment.

   If this idea is adopted by document authors, a summary I-D will be
   written containing the statistics of such adoption, as well as
   (necessarily subjective) reports by working group chairs and area
   directors who have used this mechanism.

4.3.  Success Criteria

   The eventual goal of this experiment is to improve the quality of
   IETF standards.  This is impossible to quantify, of course.  We
   suggest that generally positive answers to the following questions
   would indicate that the experiment was successful:

   o  Did the working group make more informed decisions when comparing
      multiple competing solutions for the same work item?
   o  Did authors significantly modify proposed protocols based on
      implementation experience?
   o  Did disclosure of implementations encourage more interoperability
      testing than previously?
   o  Did non-authors review documents based on interactions with
      running code and/or inspection of the code itself?
   o  Did the experiment result in toy implementations, aimed at
      "gaining points" at the IETF, or were they real and useful?

5.  Implementation Status

   This is a process document and therefore does not have any meaningful
   implementation status.  "Implementation" in the context of this
   document means actual program code.

6.  Security Considerations

   This is a process document and therefore, it does not have a direct
   effect on the security of any particular IETF protocol.  Better
   reviewed protocols are likely to also be more secure.

7.  IANA Considerations

   None.

Sheffer                   Expires June 10, 2013                 [Page 5]
Internet-Draft                Running Code                 December 2012

8.  Acknowledgements

   This document was prepared using the lyx2rfc tool, and we would like
   to thank Nico Williams, its author.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

9.2.  Informative References

   [I-D.farrell-ft]
              Farrell, S., "A Fast-Track way to Proposed Standard with
              Running Code", draft-farrell-ft-01 (work in progress),
              December 2012.

   [stats]    Arkko, J., "Distribution of Processing Times",
              December 2012,
              <http://www.arkko.com/tools/lifecycle/wgdistr.html>.

Author's Address

   Yaron Sheffer
   Porticor
   10 Yirmiyahu St.
   Ramat HaSharon  47298
   Israel

   Email: yaronf.ietf@gmail.com

Sheffer                   Expires June 10, 2013                 [Page 6]