Network Working Group D. Cridland Internet-Draft Arcode Corporation Intended status: Experimental September 03, 2013 Expires: March 07, 2014 On Popularity versus Quality draft-cridland-rfc-labels-00 Abstract Any RFC is typically seen as having the approval of the IETF community; Standards Track documents even more so. This document explores the distinction between approval based on specification quality, and approval based on high deployment. 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 March 07, 2014. Copyright Notice Copyright (c) 2013 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. Cridland Expires March 07, 2014 [Page 1] Internet-Draft RFC Labels September 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Document Labels . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Quality -- Technical Quality . . . . . . . . . . . . . . 3 2.2. Popularity -- Deployment Levels . . . . . . . . . . . . . 3 2.3. Interaction with the Standards Track . . . . . . . . . . 4 2.4. Workload Considerations . . . . . . . . . . . . . . . . . 4 3. Experimental Conditions and Outcome . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. Informative References . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Many widely deployed protocols -- particularly in the applications space -- were initially developed and sometimes deployed, without IETF involvement. This can lead to a circumstance whereby the protocol is difficult to change, yet has design choices which are undesirable. This in turn sets up a conflict between pragmatic engineering -- the desire to maintain operational deployments -- and longer term architectural engineering -- the desire to maintain the Internet as a whole. IETF participants desire that its work is relevant, useful, and deployed; however we also wish to set a high bar for that work. This can be seen as a distinction between "Popularity" -- how widely deployed a particular protocol is -- and "Quality" -- how well- designed the protocol is. Both of these are conflated in the Standards Process documented in [RFC2026], imposing a conflict where the two ideals are in opposition. The two axes may be orthogonal, of course, and this document proposes explicitly documenting them in order to minimize the conflict between them, enabling the IETF to advance lower quality protocols in good faith, or note that high quality protocols have low deployment. 2. Document Labels This memo proposes the assignment of labels indicating explicitly the technical quality and deployment level of a particular document. These labels should be visible on the RFC index, and made available via a simple web-based API to allow their integration in other RFC viewers such as the Tools renderings, etc. Cridland Expires March 07, 2014 [Page 2] Internet-Draft RFC Labels September 2013 2.1. Quality -- Technical Quality Technical quality is a nebulous thing. [RFC2026] mentions this as a requirement for advancement, but discusses this only briefly. "Technical excellence" is documented as a goal of the process, however, so this document assumes that high quality remains a goal. Since technical quality is necessarily subjective, this needs to be decided by consensus. The technical quality of a document can change -- the most obvious example is where a security issue is found, however other operational impacts may be discovered well after publication. This document proposes three levels of technical quality: High Quality The document is considered to have high technical quality, and is not known to have any technical issues if implemented correctly as specified (subject to published errata and any supporting documents). Not Evaluated The document may not been evaluated by the IETF community and may have technical issues which affects its use in the field. Technical quality may also be irrelevant to this specification. Low Quality This specification is known to have technical issues. For Standards Track documents, the IETF community has carefully reviewed the flaws and the consensus is to publish or maintain the Standards Track status of the document despite these. 2.2. Popularity -- Deployment Levels Deployment levels naturally change during a protocol's lifetime. Implementation and deployment are a key factor in advancement along the Standards Track, particularly at higher levels. There are two factors at play here -- the number of deployments and the number of implementations; this document conflates these at present. Deployment levels are by their nature objective, so it would seem reasonable for these to be simply proposed and accepted if there are no objections. If objections are found post-facto, an appeal would be reasonable. This document proposes four deployment levels: Cridland Expires March 07, 2014 [Page 3] Internet-Draft RFC Labels September 2013 Wide Deployment The protocol described by this document is widely deployed to the point of ubiquity within its target audience. New implementors can rely on the behaviour being available in the vast majority of cases. Not Evaluated The protocol's deployment is unknown. Medium Deployment The protocol described by this document is deployed, but not to the point of ubiquity. New implementors will encounter this behaviour available in some, but not all, other implementations. Low Deployment The protocol described by this document is known to have low deployment at this stage. New implementors cannot rely on the behaviour being available in other implementations. A problem here is that we do not wish to discourage new implementations of low-deployment protocols; quite the opposite in fact. However it seems likely that any document marked as Low Deployment will be considered dead. 2.3. Interaction with the Standards Track Both the quality and deployment axes overlap with the Standards Track to an unavoidable extent; the intent here is that a Standard is likely to have High Quality and Wide Deployment typically, but a document might fall to Low without moving off the Standards Track to Historic if the flaws aren't considered fatal. Initial labels for most documents should be "Not Evaluated" in both cases. For Standards, we may wish to initialize the labels to "Wide Deployment" and "High Quality". 2.4. Workload Considerations For the existing corpus of RFCs, assigning labels will undoubtedly be a significant amount of work. The labelling system as proposed attempts to mitigate this by explicitly providing for a "Not Evaluated" label in both cases; presumably any new documents would have labels proposed by the authors or Working Group. It is further assumed that proponents of a particular set of protocols (such as SIP, Mail, DNS, etc) will be best placed to propose label assignments of existing documents as desired, in order to properly document existing practises. 3. Experimental Conditions and Outcome Cridland Expires March 07, 2014 [Page 4] Internet-Draft RFC Labels September 2013 This document proposes using the above labelling system for a period of 6 months from the publication of this document as an RFC, within two protocol groupings, DNS and Mail. The outcome will be a consensus call on whether the additional information has been useful, and whether sufficient labelling of new and existing documents has been performed. 4. Security Considerations Protocol quality is thought by many to directly impact security; documenting explicitly the quality of protocols might aid those implementing and/or deploying a particular protocol. 5. IANA Considerations This document doesn't require any IANA registration or action. 6. Acknowledgements Nobody yet. 7. Informative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Author's Address Dave Cridland Arcode Corporation 4304 East West Highway Bethesda, MD US Email: dcridland@arcode.com Cridland Expires March 07, 2014 [Page 5]