Re: Review of: Characterization of Proposed Standards

Barry Leiba <barryleiba@computer.org> Sat, 02 November 2013 22:18 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DB611E8251 for <ietf@ietfa.amsl.com>; Sat, 2 Nov 2013 15:18:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.957
X-Spam-Level:
X-Spam-Status: No, score=-101.957 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3TuIEl4nWR7 for <ietf@ietfa.amsl.com>; Sat, 2 Nov 2013 15:18:20 -0700 (PDT)
Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF7411E824F for <ietf@ietf.org>; Sat, 2 Nov 2013 15:18:20 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id k4so222803qaq.19 for <ietf@ietf.org>; Sat, 02 Nov 2013 15:18:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3h/Yx7mOxYcxSXPBlG0EiTrHjP1spGIxQRoyAZu9/Zs=; b=cWSPhPt9IObaPzENKdojG50VCrMWbMt8m6UXt1KF2YB/YVeTNSpP65+OIWhdrB+ew3 VudISZeJwxmUvrPQJ/YyHXHwuVuG8viieNwsOkkmK055eqsRkS35J0CFmWgxRSos3V7a BAVfNyd0t8j4uOKzwkuFAaWvHJCsYwQS+HEPcDEAig1aSwzFbohBDoyrPYzH3yBj8dR+ pirvwO3zMMGt4G0h4MMsHQrL6rpP+106HbKwVChLPhINoltZl8E8kSmAagv9igxt4ZBV U5BJkHnvlfcjWcpLgCNHLNx4YRyIFjL6MVvu2DJPMoVGfaicmajIAyCWayfzMRQmsqTY /JLA==
MIME-Version: 1.0
X-Received: by 10.224.80.4 with SMTP id r4mr12824786qak.69.1383430699606; Sat, 02 Nov 2013 15:18:19 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.224.67.130 with HTTP; Sat, 2 Nov 2013 15:18:19 -0700 (PDT)
In-Reply-To: <CALaySJJ_o=YTgmzsUmJRWfNwH1-5DnhyKF_xDXa8nKQ=5_-jRQ@mail.gmail.com>
References: <5269209F.3060706@dcrocker.net> <B4B31C25-C472-41B3-AAF8-96670E0E243F@NLnetLabs.nl> <52729C1D.7010400@dcrocker.net> <CAC4RtVCewEKatJKJnBbCqgsuBjHCOHY49WoTx+y-K_zDt+Smxg@mail.gmail.com> <40AFC5D09A1926489ECFED9D7633D98A20045B@ESESSMB307.ericsson.se> <CALaySJJ_o=YTgmzsUmJRWfNwH1-5DnhyKF_xDXa8nKQ=5_-jRQ@mail.gmail.com>
Date: Sat, 02 Nov 2013 18:18:19 -0400
X-Google-Sender-Auth: WOE-pFhGVcsPFtO46vRxb_QUFog
Message-ID: <CALaySJKC+hP5SRn5-Euh7ugjRB-iQU5Wd090PKh-W+F8Y7adxQ@mail.gmail.com>
Subject: Re: Review of: Characterization of Proposed Standards
From: Barry Leiba <barryleiba@computer.org>
To: Jari Arkko <jari.arkko@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "<draft-kolkman-proposed-standards-clarified.all@tools.ietf.org>" <draft-kolkman-proposed-standards-clarified.all@tools.ietf.org>, Dave Crocker <dcrocker@bbiw.net>, IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Nov 2013 22:18:21 -0000

> On the Sec 3.2 point, I think Olaf is getting somewhere in his reply: make
> this the definitive source, which should eliminate the issue of duplication
> and also merge in the 6410 stuff.  I'll work up text on the plane (en route
> to EWR now.

OK, so...

Here's what I suggest, which has us explicitly replacing all of the
definitions of Proposed Standard and Internet Standard from both 2026
and 6410.  This leaves us with the new document being the definitive
place, and there's no duplication.

Abstract

OLD
   RFC 2026 describes the review performed by the IESG on IETF Proposed
   Standard RFCs and characterizes the maturity level of those
   documents.  This document updates RFC 2026 by providing a current and
   more accurate characterization of Proposed Standards.
NEW
   RFC 2026 describes the review performed by the IESG on IETF Standards
   Track RFCs and characterizes the maturity level of those documents.
   RFC 6410 updates those characterizations.  This document updates RFCs
   2026 and 6410 by providing a current and more accurate characterization
   of Proposed Standard, and merging the changes made to Internet Standard
   by RFC 6410.
END

1.  Introduction

OLD
   This document only updates the characterization of Proposed Standards
   from RFC2026 Section 4.1.1 and does not speak to or alter the
   procedures for the maintenance of Standards Track documents from RFC
   2026 and RFC 6410 [RFC6410].  For complete understanding of the
   requirements for standardization those documents should be read in
   conjunction with this document.
NEW
   This document only updates the characterization of Proposed Standards
   from RFC2026 Section 4.1.1 and merges the changes made to RFC 2026
   Section 4.1.3 by RFC 6410.  While this document now provides a complete
   current characterization of the Standards Track maturity levels, for a
   complete understanding of the requirements for standardization it is
   necessary to read RFCs 2026 and 6410 in conjunction with this document.
END

3.  Characterization of Specifications

OLD
  The text in the following section replaces RFC 2026 Section 4.1.1.
  Section 3.2 is a verbatim copy of the characterization of Internet
  Standards from RFC 2026 Section 4.1.3 and is provided for convenient
  reference.
NEW
  Internet specifications go through stages of development, testing,
  and acceptance.  Within the Internet Standards Process, there are
  two stages, formally labeled "maturity levels" in the "Standards
  Track".  These maturity levels are "Proposed Standard" and
  "Internet Standard".

  This section describes the maturity levels and the expected
  characteristics of specifications at each level.  It replaces
  Section 4.1 of RFC 2026, and its subsections, and Sections 2,
  2.1, and 2.2 of RFC 6410.

  A specification may be, and indeed, is likely to be, revised as it
  advances from Proposed Standard to Internet Standard.  When a revised
  specification is proposed for advancement to Internet Standard, the
  IESG shall determine the scope and significance of the changes to the
  specification, and, if necessary and appropriate, modify the
  recommended action.  Minor revisions and the removal of unused
  features are expected, but a significant revision may require that
  the specification accumulate more experience at Proposed Standard
  before progressing.
END

OLD
3.2.  Characteristics of Internet Standards

  A specification for which significant implementation and successful
  operational experience has been obtained may be elevated to the
  Internet Standard level.  An Internet Standard (which may simply be
  referred to as a Standard) is characterized by a high degree of
  technical maturity and by a generally held belief that the specified
  protocol or service provides significant benefit to the Internet
  community.
NEW
3.2.  Characterization of IETF Internet Standard Specifications

  A specification for which significant implementation and successful
  operational experience has been obtained may be elevated to the
  Internet Standard level.  An Internet Standard (which may simply be
  referred to as a Standard) is characterized by a high degree of
  technical maturity and by a generally held belief that the specified
  protocol or service provides significant benefit to the Internet
  community.

  The IESG, in an IETF-wide Last Call of at least four weeks, confirms
  that a document advances from Proposed Standard to Internet Standard.
  The request for reclassification is sent to the IESG along with an
  explanation of how the criteria have been met.  The criteria are:

  (1) There are at least two independent interoperating implementations
      with widespread deployment and successful operational experience.

  (2) There are no errata against the specification that would cause a
      new implementation to fail to interoperate with deployed ones.

  (3) There are no unused features in the specification that greatly
      increase implementation complexity.

  (4) If the technology required to implement the specification
      requires patented or otherwise controlled technology, then the
      set of implementations must demonstrate at least two independent,
      separate and successful uses of the licensing process.

  After review and consideration of significant errata, the IESG will
  perform an IETF-wide Last Call of at least four weeks on the
  requested reclassification.  If there is consensus for
  reclassification, the RFC will be reclassified without publication of
  a new RFC.

  In a timely fashion after the expiration of the Last Call period, the
  IESG shall make its final determination and notify the IETF of its
  decision via electronic mail to the IETF Announce mailing list.  See
  Section 6.1.2 of RFC 2026.

  A specification that reaches the status of Standard is assigned a
  number in the STD series while retaining its RFC number.
END

--
Barry