Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Nico Williams <nico@cryptonector.com> Sat, 01 February 2020 02:07 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A40A8120838 for <tls@ietfa.amsl.com>; Fri, 31 Jan 2020 18:07:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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, RCVD_IN_MSPIKE_H2=-0.001, 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 EqlAdtioHZQa for <tls@ietfa.amsl.com>; Fri, 31 Jan 2020 18:07:37 -0800 (PST)
Received: from aye.elm.relay.mailchannels.net (aye.elm.relay.mailchannels.net [23.83.212.6]) (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 6C001120BF4 for <tls@ietf.org>; Fri, 31 Jan 2020 18:07:37 -0800 (PST)
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 B76F8501EA5; Sat, 1 Feb 2020 02:07:36 +0000 (UTC)
Received: from pdx1-sub0-mail-a43.g.dreamhost.com (100-96-216-4.trex.outbound.svc.cluster.local [100.96.216.4]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 48F83501DD1; Sat, 1 Feb 2020 02:07:36 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a43.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.18.5); Sat, 01 Feb 2020 02:07:36 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Dime-Trade: 3ec3e5b56e67fc61_1580522856541_4152990526
X-MC-Loop-Signature: 1580522856541:1158542369
X-MC-Ingress-Time: 1580522856541
Received: from pdx1-sub0-mail-a43.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a43.g.dreamhost.com (Postfix) with ESMTP id E742680652; Fri, 31 Jan 2020 18:07:30 -0800 (PST)
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=g6Oi6VJUvBbaDM 3L7dgPRmzPsBI=; b=LOKPHFn/eQ01xiu31xLZY2mWodp78eSc7vW2tJYf1sGgzn gICRAs19zrtWMjNOc2SVoGSo1HfooMr+7bFVPacbBrQuYi6m+wxuLUCD81gbywN6 kWgfsbIrzWRTQ2bE0bBPUVMua2B2Hfw45djA2+daqRdpTRZ65j6bddwrGrUcs=
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-a43.g.dreamhost.com (Postfix) with ESMTPSA id 4226480651; Fri, 31 Jan 2020 18:07:29 -0800 (PST)
Date: Fri, 31 Jan 2020 20:07:26 -0600
X-DH-BACKEND: pdx1-sub0-mail-a43
From: Nico Williams <nico@cryptonector.com>
To: Tommy Pauly <tpauly@apple.com>
Cc: Rob Sayre <sayrer@gmail.com>, "TLS@ietf.org" <tls@ietf.org>
Message-ID: <20200201020725.GF18021@localhost>
References: <CACsn0cngxBQTB+Pfw6t_+qsSFb0Kf8mV1U1J1UTsPJiUk=vg0w@mail.gmail.com> <20200123193250.GD12073@localhost> <20200123210151.GG73491@straasha.imrryr.org> <5F5F670C-A0BD-4F38-BEFF-192C171EDAC1@apple.com> <20200131235533.GA18021@localhost> <CAChr6Sz6PEgQUQg8dB9Ym0z5_iRjmZE5g1hUCCgEOsA-7A=P-w@mail.gmail.com> <20200201011115.GB18021@localhost> <CAChr6SywucrTUsAeN6Aw26ufmhcB8txAmFVNGnUaeR3gG653VQ@mail.gmail.com> <20200201012302.GC18021@localhost> <C68AD2F6-E8AC-4AC1-AD66-6355997D02C7@apple.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C68AD2F6-E8AC-4AC1-AD66-6355997D02C7@apple.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrgedugdegvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomh
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dWPmrTQRoAZ_IK2y3kCVvqNujLk>
Subject: Re: [TLS] WGLC for draft-ietf-tls-ticketrequests
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Feb 2020 02:07:42 -0000

On Fri, Jan 31, 2020 at 05:59:23PM -0800, Tommy Pauly wrote:
> As a point on the process, I don't think anyone is proposing
> rubber-stamping. We are instead only suggesting that a set of work
> that has consensus does not need to be held up by adding new work that
> does not have consensus.

A substantive issue was raised.  Until that is disposed of through
normal consensus-finding mechanisms, there is no consensus for the I-D
to progress.  That's how the process works.

> The outcome of points raised during a WGLC does not need to be a
> change in the document, if the group does not have consensus that the

Correct.  But first that consensus needs to be reached.

> suggested change is correct. Particularly, as in this case, a comment
> during WGLC to add new functionality that is not part of addressing
> [...]

That's not how the process works.  Of course a substantive issue raised
at WGLC or IETF LC time (or IESG review time) can require new
functionality to be addressed properly!

There is no rule that no functionality may be added as a result of a
WGLC/IETF LC comment.  Or that comments that would require new
functionality can be rejected by the I-D's authors alone.

Nico
--