| Network Working Group | D.A. Cridland |
| Internet-Draft | Arcode Corporation |
| Intended status: Experimental | September 03, 2013 |
| Expires: March 07, 2014 |
On Popularity versus Quality
draft-cridland-rfc-labels-00
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.
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 (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.
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.
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.
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:
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:
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.
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".
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.
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.
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.
This document doesn't require any IANA registration or action.
Nobody yet.
| [RFC2026] | Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. |