Internet DRAFT - draft-cridland-rfc-labels
draft-cridland-rfc-labels
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]
