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

Nico Williams <nico@cryptonector.com> Thu, 04 July 2019 05:28 UTC

Return-Path: <nico@cryptonector.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 1450E120044 for <ietf@ietfa.amsl.com>; Wed, 3 Jul 2019 22:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 vFD8yJGpCdi6 for <ietf@ietfa.amsl.com>; Wed, 3 Jul 2019 22:28:48 -0700 (PDT)
Received: from chocolate.birch.relay.mailchannels.net (chocolate.birch.relay.mailchannels.net [23.83.209.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C58120018 for <ietf@ietf.org>; Wed, 3 Jul 2019 22:28:47 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id CF1BB1A0DA5; Thu, 4 Jul 2019 05:28:46 +0000 (UTC)
Received: from pdx1-sub0-mail-a20.g.dreamhost.com (100-96-14-11.trex.outbound.svc.cluster.local [100.96.14.11]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 32DBA1A1359; Thu, 4 Jul 2019 05:28:46 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a20.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.3); Thu, 04 Jul 2019 05:28:46 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Bottle-Oafish: 1617975a4bb49d68_1562218126543_2350432664
X-MC-Loop-Signature: 1562218126543:2536749479
X-MC-Ingress-Time: 1562218126542
Received: from pdx1-sub0-mail-a20.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a20.g.dreamhost.com (Postfix) with ESMTP id E2FFA7F461; Wed, 3 Jul 2019 22:28:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=4/muBpI2riEeBAk77Az9w7c3Y1g=; b=JK/6L1D3/JS MhVsvgxfHuld4pPlNKtXxqtPdvHAOStaeS7mDGIVzIJVS+TDQz/cRrmrCiogU+Rf edQwnJRYS9u2JgDDeGJYxvz/F1LPcaHAjCBDTMdxjoMD+zPsYJkux73VYJo9qZYr tDCQivd8S/3Ld37HUzTz6So+kRjnhNYo=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a20.g.dreamhost.com (Postfix) with ESMTPSA id 973AE7F463; Wed, 3 Jul 2019 22:28:39 -0700 (PDT)
Date: Thu, 04 Jul 2019 00:28:37 -0500
X-DH-BACKEND: pdx1-sub0-mail-a20
From: Nico Williams <nico@cryptonector.com>
To: heather flanagan <hlflanagan@gmail.com>
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, IETF discussion list <ietf@ietf.org>
Subject: Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.
Message-ID: <20190704052836.GG3508@localhost>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <632BE180-5B82-4386-85D6-712BE4DF16B4@gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrfedugdeljecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderjeenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/fvGVd3ockCKKj-J51WCcGkNT09U>
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 05:28:50 -0000

On Wed, Jul 03, 2019 at 03:33:09PM -0700, heather flanagan 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. 

An alternative would be to have interop test events.  The IETF does not
hold any such.  Sun used to host an annual interop test event (named
"Connectathon").  Perhaps the IETF/ISOC should host one.

That said, for some RFCs we've had many I-D versions prior to
publication, with a certain degree of stability being understood at some
point.  Formalizing that wouldn't be a bad idea, provided that it is
understood that IETF and IESG review can force backwards-incompatible
changes.

> If it means that the technical quality of the specifications published
> in the RFC Series improves, then that’s an idea I’d like to talk about
> to see if it has enough benefits to outweigh the risks of trying it
> out. So, that said, I’m hoping the side meeting makes sure we’ve
> identified the risks well enough to know what we’re up against.

+1

Nico
--