Re: Things that used to be clear (was Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)

Nico Williams <nico@cryptonector.com> Thu, 04 July 2019 19:21 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 14529120223 for <ietf@ietfa.amsl.com>; Thu, 4 Jul 2019 12:21:10 -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 bkE4EVCmADOo for <ietf@ietfa.amsl.com>; Thu, 4 Jul 2019 12:21:07 -0700 (PDT)
Received: from bongo.elm.relay.mailchannels.net (bongo.elm.relay.mailchannels.net [23.83.212.21]) (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 762821201EF for <ietf@ietf.org>; Thu, 4 Jul 2019 12:21:07 -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 80DD6141A24; Thu, 4 Jul 2019 19:21:06 +0000 (UTC)
Received: from pdx1-sub0-mail-a100.g.dreamhost.com (100-96-23-68.trex.outbound.svc.cluster.local [100.96.23.68]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id CE272141A71; Thu, 4 Jul 2019 19:21:05 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a100.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 19:21:06 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Abortive-Lonely: 39645f1c4e8824f6_1562268066192_2382474627
X-MC-Loop-Signature: 1562268066192:3272492221
X-MC-Ingress-Time: 1562268066192
Received: from pdx1-sub0-mail-a100.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a100.g.dreamhost.com (Postfix) with ESMTP id C09807FFAC; Thu, 4 Jul 2019 12:21:02 -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; s=cryptonector.com; bh=CpfgFZsvrTQuOv lFjzv0wGjm98E=; b=bqhL78ZnqMtcbHEDwUhXKE7Chu50lzWXlv4JMpdGMG85VR KdJk/D16Ez2OFqeP+FredG6cNAFW0q7jTWRdOBlUUYyB1yxpvIBMsnIE4ERA2VFl BZcuUozKewEZ3qs0UXQDevPRrKvA793oL0ejKhqHeSpcbMqxTqKctV/TiQlCY=
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-a100.g.dreamhost.com (Postfix) with ESMTPSA id 8D2447FFA7; Thu, 4 Jul 2019 12:21:01 -0700 (PDT)
Date: Thu, 04 Jul 2019 14:20:59 -0500
X-DH-BACKEND: pdx1-sub0-mail-a100
From: Nico Williams <nico@cryptonector.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Keith Moore <moore@network-heretics.com>, IETF discussion list <ietf@ietf.org>
Subject: Re: Things that used to be clear (was Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)
Message-ID: <20190704192057.GI3508@localhost>
References: <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> <CAHw9_i+UBs85P+gjcF6BJd1_WD2qFrrYCnXb4rtcG9Hepqm37w@mail.gmail.com> <796c1f6c-cd67-2cd5-9a98-9059a0e516f8@network-heretics.com> <20190704013009.dlifopcbm2umnqo7@mx4.yitter.info> <b18809df-ee98-fb29-b6c4-04ed579e163a@network-heretics.com> <20190704052335.GF3508@localhost> <CABcZeBOw6w2tm4YYFdmLwC23ufPDupt2D1Vzwjn4Pi9bbf6R-w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBOw6w2tm4YYFdmLwC23ufPDupt2D1Vzwjn4Pi9bbf6R-w@mail.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: gggruggvucftvghtrhhoucdtuddrgeduvddrfedvgddufeelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/0QWsWuQEATdnG5OVdB1ed64DSXs>
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 19:21:10 -0000

On Thu, Jul 04, 2019 at 08:31:47AM -0700, Eric Rescorla wrote:
> Ignoring labelling for a moment, in a number of WGs (HTTP, TLS, and
> QUIC) we have found it necessary to have full implementations and
> large-scale deployments quite early in the design process, long before
> anyone thinks that the document is done.

I had that experience in mind.

Except for QUIC (whose implementors and deployers understood and
expected to have to make backwards-incompatible changes / move to HTTP/2
and /3), HTTP/2 and TLS 1.3 didn't get widespread deployment during this
process.  But they did get some, and that "some deployment" was
absolutely critical to their success.

> Common practice has become something like this:
> 
> [...]
> 
> This does not really fit into the PS/DS model: We absolutely need
> to deploy early versions to find potential issues (this was critical
> to TLS 1.3) but we all know that those documents don't meet the PS
> bar as they may have known defects or at least open issues. There's
> also no real use for Full Standard. The market doesn't care about it
> and the people who are doing the work either are (1) fixing/extending
> the protocol (using the process above) or (2) have moved onto some
> other protocol.

Not only that, but when a WG has the energy for this, it's the only way
to move at a pace that doesn't kill that energy.

    I-D -> PS -> DS -> STD  ==  fizzle

> It's not clear to me how well this Evolving Documents proposal would
> fit into such a model [0], but I thought a field report on what is becoming
> common practice might be useful.
> 
> -Ekr
> 
> [0] The real need I find is to be able to make minor fixes to the
> documents (mostly editorial errata or clarification of points on which
> there was consensus) without re-spinning the RFC, which people don't
> have the energy for.

And if we're going to continue to have STDs, then we'll want to have
tooling for submission of implementation, deployment, and interop
reports.

Also, if we want to stick to the idea of removing parts of PSes that are
not interop tested, then we might want to have a more formal way of
marking every "feature" that needs interop testing.  Heck, even if we do
drop that old idea, we should do this.

Perhaps we could take a page from specs like x.680 and x.690 and
friends, which have lots of very short sub-sections that match closely
to features that one could then list by their section numbers.

Nico
--