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

Nico Williams <nico@cryptonector.com> Fri, 05 July 2019 18:00 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 2B2CD1200C5 for <ietf@ietfa.amsl.com>; Fri, 5 Jul 2019 11:00:54 -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 Rzf-ngfteZ15 for <ietf@ietfa.amsl.com>; Fri, 5 Jul 2019 11:00:52 -0700 (PDT)
Received: from azure.elm.relay.mailchannels.net (azure.elm.relay.mailchannels.net [23.83.212.7]) (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 994621200BA for <ietf@ietf.org>; Fri, 5 Jul 2019 11:00:51 -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 E92441A117E; Fri, 5 Jul 2019 18:00:49 +0000 (UTC)
Received: from pdx1-sub0-mail-a16.g.dreamhost.com (100-96-11-45.trex.outbound.svc.cluster.local [100.96.11.45]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 598071A1A8C; Fri, 5 Jul 2019 18:00:49 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a16.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); Fri, 05 Jul 2019 18:00:49 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Language-Turn: 41bc119f09b2952b_1562349649732_1136571328
X-MC-Loop-Signature: 1562349649732:1498588429
X-MC-Ingress-Time: 1562349649732
Received: from pdx1-sub0-mail-a16.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a16.g.dreamhost.com (Postfix) with ESMTP id 0823A7FAD2; Fri, 5 Jul 2019 11:00:44 -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=12COvLqcxG2mx482uPmO7dieppA=; b=WD+j1JGDKmO DLj49Fz7V16FZgnDMhraz1/mxpNvUk1Nh7JtAA4Cz0fk+CaAVhIrkxLYQvQAs2FC bqqhMn8oZcGhN8aNR0dC1yvs9Ng4JM1u7LqoHF942OF/+TIIZrwADgGI2sn29DB0 7Uypue+g8cawdGD1YJpqqxsWaNhmNFts=
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-a16.g.dreamhost.com (Postfix) with ESMTPSA id 321877FAB1; Fri, 5 Jul 2019 11:00:41 -0700 (PDT)
Date: Fri, 05 Jul 2019 13:00:37 -0500
X-DH-BACKEND: pdx1-sub0-mail-a16
From: Nico Williams <nico@cryptonector.com>
To: Ted Lemon <mellon@fugue.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, 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: <20190705180036.GL3508@localhost>
References: <CABcZeBOw6w2tm4YYFdmLwC23ufPDupt2D1Vzwjn4Pi9bbf6R-w@mail.gmail.com> <20190704192057.GI3508@localhost> <CABcZeBMC-VRfea3YqLSs6yhtEq4VtfdO5L56v87KH=vMR4y=+A@mail.gmail.com> <5c9048ef-ba2b-a362-3941-82eacc664b64@mnt.se> <CABcZeBPv8xUMbSt+SDL_X56SBB_CPyBMKZaQMbPd=6M-xT+hpQ@mail.gmail.com> <19233.1562339969@localhost> <20190705163101.GJ3508@localhost> <E49856E1-4DBC-488E-AE15-D48B5357E61D@fugue.com> <20190705172833.GK3508@localhost> <129605FD-CA58-4B46-8942-D2BC9E7D6716@fugue.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <129605FD-CA58-4B46-8942-D2BC9E7D6716@fugue.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrfeeggdduvdduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtugfgjggfsehtkeertddtreejnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/mfNzENWIqpKlGK8RurrlEPWMNE8>
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: Fri, 05 Jul 2019 18:00:54 -0000

On Fri, Jul 05, 2019 at 01:45:36PM -0400, Ted Lemon wrote:
> This is the essence of the problem, and you’ve proposed a solution
> that’s incompatible with it.   If it were possible to do your
> solution, I would agree with it.

So would I :(

> I’m not sure there is a solution, but it would be interesting to see
> if there is something left once we throw out the “should be expected”
> idea.   Is there a way to do more interim reviews?   What is actually
> stopping us from doing this stuff?

To do more interim reviews all we have to do is request them.  (And
teach WG chairs to do so.)

Lack of cycles is almost certainly what will be stopping us once we try.
A perception that we lack the cycles is almost certainly what is
implicitly stopping us from even thinking about interim reviews.

> A lot of times what stops me is that the document is badly written and
> difficult to read, and so it’s so much work to read it that I put it
> off until it’s too late, or give up.  It may be that it’s possible for
> us to get better at writing understandable and readable documents, and
> that this would have a greater positive impact on the process than
> shoulding at directorates.

"Too difficult to read your document" is a useful interim review!

"Don't come back until you've made this easier to review.  Here are some
example RFCs; look at the I-Ds that led to their publication."  -- also
useful.

> What’s nice about getting better at writing understandable documents
> is that it’s the authors who would have to do this, and they are
> motivated to do what it takes to get more review (or if they aren’t,
> maybe it’s okay that the document died).

We could use having classes about how to write I-Ds.

I'll note that the ITU-T writes beautiful specs.  I find the x.68x
(ASN.1) and x.69x (ASN.1 encoding rules) series to be brilliantly
written.  But that's an SDO that costs $$$$ to participate in, and uses
that money to produce quality results.

If ISOC spent more on the RSE function, perhaps the RSE could provide
early intervention services.  But any time we think of spending a lot
more $$$ on such functions we need to think about how we keep the IETF a
volunteer organization -- whence the funding??

> Do you see this as a useful thing to attempt, and if so, do you think
> it’s possible to do it?

I'm guessing the biggest problem is that interim reviews == a bit of a
step function in reviewer cycles demand.

But we could do a pilot.  Identify a WG whose work could really use
interim reviews.  Arrange for its chairs to request them.  Run this
experiment for a while, then survey the authors, WG participants,
shepherds, interim reviews, IESG, and IETF -- was this better?  will it
scale?  Then we can think about how to scale it further than one WG.

Nico
--