Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.

Carsten Bormann <cabo@tzi.org> Thu, 04 July 2019 04:55 UTC

Return-Path: <cabo@tzi.org>
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 BFD091200CE for <ietf@ietfa.amsl.com>; Wed, 3 Jul 2019 21:55:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1kn4zvFI1xk for <ietf@ietfa.amsl.com>; Wed, 3 Jul 2019 21:55:25 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60F731200DE for <ietf@ietf.org>; Wed, 3 Jul 2019 21:55:25 -0700 (PDT)
Received: from [192.168.217.110] (p548DC676.dip0.t-ipconnect.de [84.141.198.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45fQdk15LtzySL; Thu, 4 Jul 2019 06:55:22 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <632BE180-5B82-4386-85D6-712BE4DF16B4@gmail.com>
Date: Thu, 04 Jul 2019 06:55:21 +0200
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, IETF discussion list <ietf@ietf.org>
X-Mao-Original-Outgoing-Id: 583908919.971326-9c5ef3b3e6cfcb36f86e4c498ed91c19
Content-Transfer-Encoding: quoted-printable
Message-Id: <97055BE4-CF0F-44BC-B1D5-3E3586092651@tzi.org>
References: <CAHw9_iKv7xDY-rT98F_BAEvGOGbWGL7UpXS42rSVLsHB+=SOZg@mail.gmail.com> <4567879e-aa29-aeae-72e9-33d148d30eed@network-heretics.com> <CAL02cgToQWmOrfOxS_dc4KRtT9e0PXNzmhWZHkRUyV_3V=E-mQ@mail.gmail.com> <0856af71-4d84-09d1-834d-12ac7252420c@network-heretics.com> <CAL02cgQ9qWVUTPW=Cpx=r32k3i1PLgfp5ax0pKMdH0nKObcKTg@mail.gmail.com> <e8d28a7f-128d-e8d0-17d3-146c6ff5b546@joelhalpern.com> <632BE180-5B82-4386-85D6-712BE4DF16B4@gmail.com>
To: heather flanagan <hlflanagan@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/0d6LKLqsTmQ5gc5p6MhC6c-5Q-Q>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 04 Jul 2019 04:55:29 -0000

On Jul 4, 2019, at 00:33, heather flanagan <hlflanagan@gmail.com> wrote:
> 
> One of the things that attracts me to this idea of marking specific I-Ds as stable is the possibility that the material in the I-D will be more throughly tested BEFORE it gets to the RFC Editor for publication. I see it as, potentially, a way to improve the quality of what’s published in the RFC Series. 

Most of the confusion here is about the term “stable”, because that means different things to different people.

Clearly, it’s not “stable” if it can be toppled next week.

What we occasionally do is label some draft versions as “implementation drafts” (certainly not my idea).  That designation means “it is worth implementing this now; this is no longer quicksand”.  It may simply be motivated by the need to get interop experience, so it does not mean “stable” in a more serious way; I’d rather have a different label for “we are not going to break this any more unless we really have to” label (e.g., the CDDL I-D was in that state since 2015 before it became RFC 8610; it did gain additional features during this time).

So I think providing a way for a WG to slap a useful label on a WG I-D is a good thing; standardizing on a small set of such labels is useful, but not a prerequisite.

The whole discussion is a bit of an expression of the too-high-threshold we now have for publishing things as an IETF document; there really should be a “proposed standard” level.

(Ceterum censeo: Our whole nomenclature of publications, where only some Internet standards are “Internet Standards” while the more important group is “Proposed Standards”, and valid documents are “obsoleted” by documents that are just revised editions of them, etc., is incomprehensible to casual observers and can be used and is being used against the IETF –– we really need to work on that terminology.)

Grüße, Carsten