Re: [Curdle] second AD review of draft-ietf-curdle-rc4-die-die-die-15

Benjamin Kaduk <kaduk@mit.edu> Wed, 31 July 2019 23:38 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4441200A1; Wed, 31 Jul 2019 16:38:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 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] autolearn=ham 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 cMWR0rPbPQ-m; Wed, 31 Jul 2019 16:38:47 -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 4925F120043; Wed, 31 Jul 2019 16:38:47 -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 x6VNcgbc000310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Jul 2019 19:38:45 -0400
Date: Wed, 31 Jul 2019 18:38:42 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Loganaden Velvindron <loganaden@gmail.com>
Cc: draft-ietf-curdle-rc4-die-die-die.all@ietf.org, curdle <curdle@ietf.org>
Message-ID: <20190731233841.GO1006@kduck.mit.edu>
References: <20190730212232.GP47715@kduck.mit.edu> <CAOp4FwR7mAOmicA-gQZxuYrc-+2rsB=oW08Fc_YjP=4fZL0H-Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAOp4FwR7mAOmicA-gQZxuYrc-+2rsB=oW08Fc_YjP=4fZL0H-Q@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/2g0d1mmXif2p9wfMJWCVxngWSwI>
Subject: Re: [Curdle] second AD review of draft-ietf-curdle-rc4-die-die-die-15
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jul 2019 23:38:49 -0000

On Wed, Jul 31, 2019 at 11:30:42AM +0400, Loganaden Velvindron wrote:
> On Wed, Jul 31, 2019 at 1:22 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
> >
> > Hi all,
> >
> > I'm just about ready to send this document into IESG Evaluation, but
> > noticed a few nits while rereading it.  Since they're in areas that I
> > expect the IESG to be looking at, I'd like to have an updated revision of
> > the document available before I send it out to the IESG as a whole:
> >
> > draft-ietf-curdle-des-des-des-die-die-die is now RFC 8429, so we can update
> > that reference.
> >
> > Additionally, part of the holdup for that document was to decide whether to
> > Obsolete RFC 4757 or move it to Historic, since we cannot do both.  The
> > Abstract of this document still says that it both Obsoletes and moves to
> > Historic RFC 4345 (and it has the Obsoletes: header); since we decided in
> > the RFC 8429 case to use "move to Historic", I think that's the right thing
> > to do here as well.  So we want to keep the "move to Historic" text but
> > drop the in-document and metadata "Obsoletes:" relationship.
> > (https://www.ietf.org/blog/iesg-statement-designating-rfcs-historic/ has
> > some more background on the difference.)
> >
> > On the other hand, since we are updating RFC 4253, we do need to mention
> > Updates: 4253 in document header.
> >
> > We can also update to use the RFC 8174 version of the BCP 14 boilerplate.
> >
> > Finally, the table in Section 3 seems to be formatted oddly, with the
> > column break appearing in the middle of "Encryption Algorithm Name" instead
> > of at the end of it.
> >
> 
> Thank you Benjami.
> 
> I've sent in -16. See the diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-rc4-die-die-die-16

Thanks; I'll be sending both of these documents to the IESG shortly!

-Ben