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

Heather Flanagan <rse@rfc-editor.org> Thu, 04 July 2019 15:04 UTC

Return-Path: <rse@rfc-editor.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 473E112013A for <ietf@ietfa.amsl.com>; Thu, 4 Jul 2019 08:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 y644V6ftt1Lx for <ietf@ietfa.amsl.com>; Thu, 4 Jul 2019 08:04:45 -0700 (PDT)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689EA120134 for <ietf@ietf.org>; Thu, 4 Jul 2019 08:04:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id BFAA61C1380; Thu, 4 Jul 2019 08:04:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1wkqDrXFYiN; Thu, 4 Jul 2019 08:04:27 -0700 (PDT)
Received: from [10.198.42.38] (c-71-231-216-10.hsd1.wa.comcast.net [71.231.216.10]) by c8a.amsl.com (Postfix) with ESMTPSA id 80B511C1370; Thu, 4 Jul 2019 08:04:27 -0700 (PDT)
From: Heather Flanagan <rse@rfc-editor.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.
Date: Thu, 04 Jul 2019 08:04:43 -0700
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> <97055BE4-CF0F-44BC-B1D5-3E3586092651@tzi.org>
To: Carsten Bormann <cabo@tzi.org>, IETF discussion list <ietf@ietf.org>
In-Reply-To: <97055BE4-CF0F-44BC-B1D5-3E3586092651@tzi.org>
Message-Id: <89410949-AE60-4893-9CED-92D0FBABD2F0@rfc-editor.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/sE3i4s0N80TB3cDYuh80GGV651I>
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 15:04:47 -0000


> On Jul 3, 2019, at 9:55 PM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> 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.

Makes sense. I’m not married to any particular terminology for this idea. I would like the terminology to be clear and limited; as you mentioned below, we already use words that really only make sense if you’re embedded in the IETF. We don’t need to make matters worse in that regard. 

> 
> 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).

One of my early suggestions, which was not well received, was to leave the draft name alone and instead use a CSS+language in the document itself to indicate the document could be considered an implementation draft. But the concern over bike-shedding the CSS was, I think, death to this idea. A shame; seams like a reasonable tool for the effort.

> 
> 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.)

+1

-Heather