IETF Logo Mail Archive

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

Tommy Pauly <tpauly@apple.com> Sat, 01 February 2020 01:59 UTC

Return-Path: <tpauly@apple.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 19350120045 for <tls@ietfa.amsl.com>; Fri, 31 Jan 2020 17:59:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 jrt2QuGTRigE for <tls@ietfa.amsl.com>; Fri, 31 Jan 2020 17:59:31 -0800 (PST)
Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 30F59120024 for <tls@ietf.org>; Fri, 31 Jan 2020 17:59:31 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id 0111q7gd052512; Fri, 31 Jan 2020 17:59:28 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=nPfhLXBXWHmhUuhwXQF8deHpHrQ5QI8ildac384FgJI=; b=F1Sci9Ufrs/z0OBl9dwk3TIvU5YJCD6qhe1KIqiMucbY+32YoUw2y/ArxFMNe0U2NKHv /FpZtBptp5kwiHWqUYVshRZ3rTVcQ0Qaaq+4CHEGwt/GMsWjEQTfLkWj7k5W4ZI4q/2d FlCL3O1GvwYN+icaswqxAnDLUrGDDhA2VqLMKZkDznDAK1ifqbOJhOCpQQTB8Gkdf/KN SqlkYEJnspzUbiAo+Jx2CilMGTu4ZDYsusPfHJ1E2VF6vzdfeaX1InokCDnhJqNDztZB 89picS0I5T3nh4rL0+44pF9fAq/zZpp1f0iqxNlGufEqA+UUJZvzY78x7gs2TyH+/u+f RA==
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2xrn7b0fug-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 31 Jan 2020 17:59:28 -0800
Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPS id <0Q50011KS2V4IB30@rn-mailsvcp-mta-lapp04.rno.apple.com>; Fri, 31 Jan 2020 17:59:28 -0800 (PST)
Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q5000M002LN9400@nwk-mmpp-sz11.apple.com>; Fri, 31 Jan 2020 17:59:28 -0800 (PST)
X-Va-A:
X-Va-T-CD: 697a433e6cef5d2da4e5f9329f649989
X-Va-E-CD: 7f7e14a8463c26a765e1ab3769b5d901
X-Va-R-CD: 6a2bc58b15f70a522f15c151e4c2a302
X-Va-CD: 0
X-Va-ID: 099e486b-4448-4da9-83db-efd802b3bdb5
X-V-A:
X-V-T-CD: 697a433e6cef5d2da4e5f9329f649989
X-V-E-CD: 7f7e14a8463c26a765e1ab3769b5d901
X-V-R-CD: 6a2bc58b15f70a522f15c151e4c2a302
X-V-CD: 0
X-V-ID: d456a7d0-1a2a-4140-a4dd-fbbc3a703adb
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2020-01-31_07:,, signatures=0
Received: from [17.230.168.109] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q500024M2V3SB50@nwk-mmpp-sz11.apple.com>; Fri, 31 Jan 2020 17:59:27 -0800 (PST)
Sender: tpauly@apple.com
Content-type: text/plain; charset="us-ascii"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\))
From: Tommy Pauly <tpauly@apple.com>
In-reply-to: <20200201012302.GC18021@localhost>
Date: Fri, 31 Jan 2020 17:59:23 -0800
Cc: Rob Sayre <sayrer@gmail.com>, "TLS@ietf.org" <tls@ietf.org>
Content-transfer-encoding: quoted-printable
Message-id: <C68AD2F6-E8AC-4AC1-AD66-6355997D02C7@apple.com>
References: <87427017-551e-4633-a0d3-75f378879aa9@redhat.com> <20200123124055.GF73491@straasha.imrryr.org> <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>
To: Nico Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.3594.4.17)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2020-01-31_07:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ZaZAO5jPEFrc37wpKP-LrnUh-Ag>
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 01:59:33 -0000

Hi Nico,

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.

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 suggested change is correct. Particularly, as in this case, a comment during WGLC to add new functionality that is not part of addressing the intended scope of a working group deliverable does not need to be added before progressing. I think this is a case in which we have consensus on the basic ticket requests, but adding ticket reuse is (based on the way this thread has not converged) is in the rough. 

Thanks,
Tommy

> On Jan 31, 2020, at 5:23 PM, Nico Williams <nico@cryptonector.com> wrote:
> 
> On Fri, Jan 31, 2020 at 05:15:40PM -0800, Rob Sayre wrote:
>> If the scope of a document can be continually expanded during last call, it
>> can be indefinitely postponed.
> 
> There is no attempt to postpone, and the WGLC has finished.  No new
> issues will be raised.  But the ones that were raised _will_ be
> addressed.  Being left on the rough side of consensus happens; having
> substantive issues raised in a timely manner ignored must not.
> 
> The IETF is not a rubber-stamp SDO.  We have a process.  We don't just
> pay it lip service.  WGLC is not going through the motions.  The
> prescribed process will be followed.
> 
> Nico
> --

v2.23.0 | Report a Bug | By Email