Re: I-D Action: draft-roach-bis-documents-00.txt

"Martin Thomson" <mt@lowentropy.net> Thu, 09 May 2019 06:03 UTC

Return-Path: <mt@lowentropy.net>
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 D3A4D120108 for <ietf@ietfa.amsl.com>; Wed, 8 May 2019 23:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=LaphttNq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GpGu5j3q
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 xJcTG9Jq_c14 for <ietf@ietfa.amsl.com>; Wed, 8 May 2019 23:03:12 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F611200CD for <ietf@ietf.org>; Wed, 8 May 2019 23:03:12 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 4069734A; Thu, 9 May 2019 02:03:11 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 09 May 2019 02:03:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=CiBA8 95UOWfIKKANBDi0o3qd4yUA4FvojiPmrVgGCH0=; b=LaphttNqEma62j4Kjihr6 qOGSJBdq7kCfwYW2WWrPOeDVIxyIrBP+r3duDY1PPrjjA/3uy8tBcIdxLJ4QmDeV 7RVPzL5vfwh4TL8CjzECzLb/SCxF6TNpfWfKrewfmBbVa+El5MklQsHLkDyUqOil CysdGS7r1zV23Uoy0IOExHyVMmze6AoYaS9UPZFB2qtyi04aReXeITO0v4rqcR8v jrSRTxkRhkHMX1cSDK9QNVfeYgmHSCoNKCGXdUv1y9DJi+u+O07y9LOSOr3Gpxt4 p8PvGzSLyYk8oETLruWQYxmCZJPZr5FhyuXrQYAepyj6h0N2k07SfZkCkb5VV7+e w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=CiBA895UOWfIKKANBDi0o3qd4yUA4FvojiPmrVgGC H0=; b=GpGu5j3qW0MNx81tmEHHE2rFSGhlM4qF4+jtM2QDSOkcY2qk4+mh1sXOW 8yCPOILoxO/r8WaOLdYMUX5JW8jWrSTXDNX4Gfqn4p4J23ajSk7z74PwqWDrCTbR 3SE1u0InTurnicB55kx6n3K7JyNW3Bxw88OQwLTSBs5UOeymmHvrMNYR8WdCOxs8 9e8GnMb3cPoywyYXYqNn/oeB2k+8Bq2boZwDXvUF823Qlps+orUBKu0X/mAIWuhy GmwQiUoXbOolNuzy6kmXTEHwvLNkIOwvEH3CKmkkNIZhEe/vFKmBFQjIKKzHRfsN 0HlTPa+rMfPU9fmE2jLxAYjFid6YQ==
X-ME-Sender: <xms:nsLTXBxtwjC01kjpr5B2GjN0XfntTadUfuJSGIC0crIXgE3109dK1Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrkeeggddutddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfofgr rhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenuc frrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucev lhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:nsLTXERO1t3t3h7ZVwbod823noyfiOK-q8B7Xe6sRuVhcc1Waz8ipA> <xmx:nsLTXFNHxa2LXZ2fNJly6aKg0GYjdlsPLB5hP422a_6MeqEZsRP_Sg> <xmx:nsLTXOkJM0EnleVnevYy8tokduaNgMCF5xlmRVsL-TvrPU8M9ibF4g> <xmx:nsLTXP1klDC3ZgJcTStynJvw75L7OeeqRyDjTMFJaFjUszT3g3ZXdg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id E86047C6D9; Thu, 9 May 2019 02:03:09 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1
Mime-Version: 1.0
Message-Id: <5aca4233-d623-421a-ad6c-52caa1c7a504@www.fastmail.com>
In-Reply-To: <50f57ae9-d850-aebd-e85c-c9c13b72908e@nostrum.com>
References: <155727468140.24481.6999490968617833064@ietfa.amsl.com> <4565215f-c36c-7264-c30a-52d2f9547346@gmail.com> <400f1771-dea5-a554-7744-d2c7a8a60e3c@nostrum.com> <accbe578-19f5-4577-9734-372de677af58@www.fastmail.com> <50f57ae9-d850-aebd-e85c-c9c13b72908e@nostrum.com>
Date: Thu, 09 May 2019 02:03:10 -0400
From: Martin Thomson <mt@lowentropy.net>
To: Adam Roach <adam@nostrum.com>, ietf@ietf.org
Subject: Re: I-D Action: draft-roach-bis-documents-00.txt
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/cwTSHIkp0byS0ZOv8VpwVBSBhgk>
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, 09 May 2019 06:03:15 -0000

On Thu, May 9, 2019, at 02:30, Adam Roach wrote:
> I'm not married to the notion of an appendix, but I think the 
> description of changes benefits greatly from being in a dedicated 
> section 

Yep, it was a mere quibble.  I think that a dedicated section is a very good idea, but that the additional condition that it be hidden away is not always as good an idea.  With a small change, Section 1.4 might be better.

Take RFC 8446 as an example.  It's hardly a bis document, but it takes Sections 1.2 and 1.3, over almost two pages, for this purpose.  I don't want to invalidate that approach.  After all, we have a long-standing requirement to include some statement about what has changed in the abstract (which I assume you aren't changing).

I've no problem with a recommendation to use an appendix.  I think that those sections in TLS 1.3 are a bit of a distraction from the main event and might have been left until later in the document, but that (like much of this) is a point upon which reasonable people can disagree.

> I've had several conversations with standing and former members of the 
> IESG about the overall proposal I present in this document, and more 
> than one person got hung up on the notion of letting 
> known-to-be-deprecated approaches through without comment. Largely, 
> these involve issues that have already been documented in BCP  or 
> Standards Track documents, and which would otherwise constitute DISCUSS 
> criteria. Cast in that light, I think the enumeration of what would be 
> different in a green-field protocol is actually quite important, 
> although I concede that the current text might not capture it as clearly 
> as I like.

I think that a *strong* encouragement to perform the analysis (i.e., SHOULD) is better than an absolute mandate (MUST).  That gives the right incentive, but leaves groups that get wrapped around the axle of an old issue an option that they can exercise.

Final point, and it's a new one (sorry): Authorship.  This is likely to be a sensitive topic.  But it is probably not appropriate to replace the entire author list for a small change.  Some guidance on that would be welcome.  My suggestion would be to recognize new authors either as an additional author or editor, or even to list them in the contributors.  Like a lot of this, judgment will need to be exercised, but that should take into account the size of the change and the amount of work that was done.