Re: Review of: Characterization of Proposed Standards

Barry Leiba <barryleiba@computer.org> Sat, 02 November 2013 22:20 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 6E84011E8256 for <ietf@ietfa.amsl.com>; Sat, 2 Nov 2013 15:20:07 -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 q6mlm5j9c4vc for <ietf@ietfa.amsl.com>; Sat, 2 Nov 2013 15:20:06 -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 7BADB11E8254 for <ietf@ietf.org>; Sat, 2 Nov 2013 15:20:06 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id k4so223602qaq.12 for <ietf@ietf.org>; Sat, 02 Nov 2013 15:20:06 -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=NXeiK80ZiwdIZ4Mo03A4tgrHNeWMqCX0khmcvJyNIS8=; b=SiTWeJCRIHEJPRHo8oKufjxHv/j6qmbeNw0zYKbO1b0YWpVMMo1QKWREC/4JBUylYI De0b1/LQFtLjJK5hwuJvmuTse1Exfm0TjtZiDgi1PzuKDTKFF1CDUzFojvfQEp3fEwfP XZe8TSENu83sZFoULuKeu+WIK9sBCPcK53K9yWlYGeGFSRFGxCPqJTj2mX7nQoc+0Qim O47WJrR+EYLZkmwpqEMJ0i3iwP1hF2H/JNfQh3vP+2/LfOmMEprnfSbT1JiiDJJcGLIY iJibkSvwMfl0D2JFXYK1uN+Z38n75KJVfc4wrRSzpWVwcifPvzinz4hgUheQlinnsoUU o6yg==
MIME-Version: 1.0
X-Received: by 10.224.7.194 with SMTP id e2mr12949726qae.46.1383430806002; Sat, 02 Nov 2013 15:20:06 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.224.67.130 with HTTP; Sat, 2 Nov 2013 15:20:05 -0700 (PDT)
In-Reply-To: <CALaySJKC+hP5SRn5-Euh7ugjRB-iQU5Wd090PKh-W+F8Y7adxQ@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> <CALaySJKC+hP5SRn5-Euh7ugjRB-iQU5Wd090PKh-W+F8Y7adxQ@mail.gmail.com>
Date: Sat, 02 Nov 2013 18:20:05 -0400
X-Google-Sender-Auth: oGTYgQMR2NyJsup8Kam9uOLG3Ik
Message-ID: <CALaySJJkbjCd9M=b_gZEGk9Y3nA1KH3hFoi45Sr1Z5=UFg5HgA@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:20:07 -0000

Oh, and, of course, if we use my suggestion below, this document will
have to "update" 6410 as well as 2026.

Barry


On Sat, Nov 2, 2013 at 6:18 PM, Barry Leiba <barryleiba@computer.org> wrote:
>> 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