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]