One document matched: draft-sheffer-running-code-01.xml

<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc tocindent="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc1264 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1264.xml">
<!ENTITY rfc3933 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3933.xml">
<!ENTITY rfc4794 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4794.xml">
<!ENTITY I-D.farrell-ft PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.farrell-ft.xml">
<!ENTITY stats SYSTEM "/home/yaronf/Desktop/running-code/reference.stats.xml">
<!ENTITY tao SYSTEM "/home/yaronf/Desktop/running-code/reference.tao.xml">
]>
<rfc docName="draft-sheffer-running-code-01" ipr="trust200902" category="exp">
  <front>
    <title abbrev="Running Code">Improving “Rough Consensus” with Running Code</title>
    <author initials="Y." surname="Sheffer" fullname="Yaron Sheffer">
      <organization abbrev="Porticor">Porticor</organization>
      <address>
        <postal>
          <street>10 Yirmiyahu St.</street>
          <city>Ramat HaSharon</city>
          <code>47298</code>
          <country>Israel</country>
        </postal>
        <email>yaronf.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="A." surname="Farrel" fullname="Adrian Farrel">
      <organization abbrev="Juniper">Juniper Networks</organization>
      <address>
        <email>adrian@olddog.co.uk</email>
      </address>
    </author>
    <date month="December" year="2012"/>
    <area>
Security Area
</area>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>
This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code and potentially reward the documented protocols by treating the documents with implementations preferentially.</t>
      <t>
The process in this document is offered as an experiment. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications.</t>
      <t>
The authors of this document intend to collate experiences with this experiment and to report them to the community.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="d1e286">
      <t>
Most IETF participants are familiar with the saying, "rough consensus and running code" <xref target="tao"/>, and can identify with its pragmatic approach. However, there are many examples of Internet-Drafts containing protocol specification that have gone through to publication as Proposed Standard RFCs without implementation. Some of them may never get implemented.</t>
      <t>
Over time, a variety of policies have been implemented within the IETF to consider running code. In the Routing Area it used to be a requirement that one or more implementations must exist before an Internet-Draft could be published as a Proposed Standard RFC <xref target="RFC1264"/>. That RFC was later obsoleted and the requirement for implementation was lifted, but each working group was given the authority to impose its own implementation requirements <xref target="RFC4794"/> and at least one working group (IDR) continues to require two independent implementations.</t>
      <t>
The hypothesis behind this document is that there are benefits to the IETF standardization process of producing implementations of protocol specifications before publication as RFCs. These benefits, which include determining that the specification is comprehensible and that there is sufficient interest to implement, are further discussed in  <xref target="sec_Benefits"/>.</t>
      <t>
This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code and potentially reward the documented protocols by treating the documents with implementations preferentially.</t>
      <t>
Contrary to proposals to fast-track Internet-Drafts that have associated source code implementations <xref target="I-D.farrell-ft"/>, this document provides a mechanism to record and publicize the existence of running code. It is up to the individual working groups to use this information as they see fit, but one result might be the preferential treatment of documents resulting in them being processed more rapidly.</t>
      <t>
The process in this document is offered as an experiment. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications.</t>
      <t>
The authors of this document intend to collate experiences with this experiment and to report them to the community.</t>
    </section>
    <section title="The “Implementation Status” Section" anchor="d1e341">
      <t>
Each Internet-Draft may contain a section entitled "Implementation Status". This section, if it appears, should be located just before the "Security Considerations" section and contain, for each existing implementation:</t>
      <t>
        <list style="symbols">
          <t>
The implementation's name and/or a link to a web page describing the implementation.</t>
          <t>
A brief general description.</t>
          <t>
The implementation's level of maturity: alpha, beta, production, or widely used.</t>
          <t>
Coverage: which parts of the protocol specification are implemented and which versions of the Internet-Draft were implemented.</t>
          <t>
Licensing: whether the implementation is closed source, shareware, or open source.</t>
        </list>
      </t>
      <t>
In addition, this section can contain information about the interoperability of any or all of the implementations.</t>
      <t>
Since this information is necessarily time-dependent, the authors should remove this section when the I-D is published as an RFC.</t>
    </section>
    <section title="Alternative Formats" anchor="d1e372">
      <t>
Sometimes it can be an advantage to publish the implementation status separately from the base Internet Draft, e.g. on the IETF wiki:</t>
      <t>
        <list style="symbols">
          <t>
When the Implementation Status section becomes too large to be conveniently managed within the document.</t>
          <t>
When a working group decides to have implementors, rather than authors, keep the status of their implementations current.</t>
          <t>
When a working group already maintains an active wiki and prefers to use it for this purpose.</t>
        </list>
      </t>
      <t>
It is highly important that all readers of the Internet Draft should be made aware of this information. Initially this can be done by replacing the Implementation Status section with a URL pointing to the wiki. Later, the IETF Tools may support this functionality, e.g. by including such a link from the HTMLized draft version, similarly to the IPR link.</t>
      <t>
The implementation status information must be publicly available, in line with general IETF policy.</t>
    </section>
    <section title="Benefits" anchor="sec_Benefits">
      <t>
Publishing the information about implementations provides the working group with several benefits:</t>
      <t>
        <list style="symbols">
          <t>
Participants are motivated to implement protocol proposals, which helps in discovering protocol flaws at an early stage.</t>
          <t>
Other participants can use the software, to evaluate the usefulness of protocol features.</t>
          <t>
WG members may choose to perform interoperability testing with known implementations, especially when they are publicly available.</t>
          <t>
In the case of open source, people may want to study the code to better understand the protocol and its limitations.</t>
          <t>
Working group chairs and ADs may use the information provided to help prioritize the progress of I-Ds in some way <xref target="I-D.farrell-ft"/>.</t>
          <t>
And lastly, some protocol features may be hard to understand, and for such features, the mere assurance that they can be implemented is beneficial.</t>
        </list>
      </t>
      <t>
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.</t>
    </section>
    <section title="Process Experiment" anchor="d1e437">
      <t>
The current proposal is proposed as an experiment. The inclusion of "Implementation Status" sections in Internet-Drafts is not mandatory, but the authors of this document wish to encourage authors of other Internet-Drafts to try out this simple process to discover whether it is useful. Working group chairs are invited to suggest this process to document editors in their working groups, and to draw the attention of their working group participants to "Implementation Status" sections where they exist.</t>
      <t>
Following a community discussion, it was concluded that <xref target="RFC3933"/> is not an appropriate framework for this experiment, primarily because no change is required to any existing process.</t>
      <section title="Duration" anchor="sub_Duration">
        <t>
Given the typical time to produce an RFC (see <xref target="stats"/>), we propose a duration of 18 months for the experiment. Thus, 18 months after the date of initial posting of this document, the authors will report on the experiment as described in the next section.</t>
      </section>
      <section title="Summary Report" anchor="d1e473">
        <t>
The authors will summarize the results of the experiment at the end of the period assigned to the experiment (see  <xref target="sub_Duration"/>). If nothing happens (no I-Ds or only a handful include an "Implementation Status" section), an email to the IETF list will be sufficient. This would obviously constitute a failure to adopt the idea and the authors will abandon the experiment.</t>
        <t>
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.</t>
        <t>
The authors may then propose more wide-scale use of the process and might suggest more formal adoption of the process by the IETF.</t>
      </section>
      <section title="Success Criteria" anchor="d1e491">
        <t>
The goal of this experiment is to improve the quality of IETF specifications. This is impossible to quantify, of course. We suggest that generally positive answers to the following questions would indicate that the experiment was successful: </t>
        <t>
          <list style="symbols">
            <t>
Did the working group make decisions that were more informed when comparing multiple competing solutions for the same work item?</t>
            <t>
Did authors significantly modify proposed protocols based on implementation experience?</t>
            <t>
Did disclosure of implementations encourage more interoperability testing than previously?</t>
            <t>
Did non-authors review documents based on interactions with running code and/or inspection of the code itself?</t>
            <t>
Did the experiment result in toy implementations, aimed at “gaining points” at the IETF, or were they real and useful?</t>
          </list>
        </t>
      </section>
    </section>
    <section title="Implementation Status" anchor="d1e516">
      <t>
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.</t>
    </section>
    <section title="Security Considerations" anchor="d1e525">
      <t>
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.</t>
    </section>
    <section title="IANA Considerations" anchor="d1e535">
      <t>
None.</t>
    </section>
    <section title="Acknowledgements" anchor="d1e544">
      <t>
This document was prepared using the lyx2rfc tool, and we would like to thank Nico Williams, its author.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References" anchor="sec_References">&rfc2119;</references>
    <references title="Informative References" anchor="d1e571">&rfc1264;
&rfc3933;
&rfc4794;
&I-D.farrell-ft;
&stats;
&tao;
</references>
  </back>
</rfc>