Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05

Benjamin Kaduk <kaduk@mit.edu> Tue, 08 October 2019 12:05 UTC

Return-Path: <kaduk@mit.edu>
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 CFD22120077; Tue, 8 Oct 2019 05:05:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 6jvNOAGoxIeT; Tue, 8 Oct 2019 05:05:17 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 EF1811202A0; Tue, 8 Oct 2019 05:05:16 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x98C56m5009358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 8 Oct 2019 08:05:09 -0400
Date: Tue, 8 Oct 2019 05:05:06 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Rob Sayre <sayrer@gmail.com>, Eric Rescorla <ekr@rtfm.com>, Sean Turner via Datatracker <noreply@ietf.org>, John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>, "tls@ietf.org" <tls@ietf.org>, IESG Secretary <iesg-secretary@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>
Message-ID: <20191008120506.GF76545@kduck.mit.edu>
References: <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> <CAChr6Sx4AVjkoKWiD2-cT2ZBNg=mKzeOX603gVs0f7vQ_FgN7A@mail.gmail.com> <CABcZeBNOVOBifOSnWdxSDTLizUUUn6ctLrBT43CHK+4B7KWGiQ@mail.gmail.com> <CAChr6SzT3GqmidPbmVjmrZX=u1UpBee4e8K2C-zHuNHEqgB7uQ@mail.gmail.com> <CABcZeBOGjPYy9FaOzaf-bHKaoMtXpO0SjQO5RTx9fMUo3r8vUg@mail.gmail.com> <CAChr6SwjdhpL2jQgNVjjuLosa8ycZEi9rGHuZ=K8=ToRy-gfJw@mail.gmail.com> <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1SYsohG9BVaOlSyX_49GKVpyzpE>
Subject: Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05
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: Tue, 08 Oct 2019 12:05:18 -0000

On Mon, Oct 07, 2019 at 09:12:44PM +0100, Stephen Farrell wrote:
> 
> Hiya,
> 
> On 07/10/2019 18:29, Rob Sayre wrote:
> > On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
> > wrote:
> >> we can't "UPDATE" an I-D.
> >
> > Not true. If you need to refer to something that's been IESG-approved but
> > still in the RFC queue, you can leave a note for the RFC editor to update
> > the reference to the eventual RFC number.
> 
> That would be an UPDATE on the eventual RFC and not on the
> I-D. And in this case, it'd IMO not be a good plan as a) the

Recent IESGs have been taking the stance that it's weird to have "Updates:"
to a document that's not yet an RFC, mostly preferring to pull the document
in question back and get changed directly.  But ...

> relevant WG didn't want that, b) the I-D in question is part
> of a mega-cluster, so any dependency on it (as you suggest)
> risks loadsa delay if the cluster doesn't get unstuck, which
> can happen and c) our draft already stretches the header

... given that C238 is unblocked, dependencies-wise, that seems
questionable in this case.  (The whole set of documents does have to go
through the xmlv2-->xmlv3 conversion, though.)

> enough updating 85 RFCs - trying to add an I-D to that list
> would break tools and cause much pointless process-angst.
> 
> Mostly (a) is the reason to not do it though. If you want
> to disagree with (a), then the right list for that would be
> the rtcweb list I guess, even though the WG is now concluded
> (which could, I guess, be (d);-)
> 
> Overall, the cost isn't worth the benefit IMO.

That's roughly where I'm landing, too, though as noted previously, it's
largely up to the sponsoring AD.

-Ben