[Curdle] Mirja Kühlewind's Discuss on draft-ietf-curdle-des-des-des-die-die-die-04: (with DISCUSS)

Mirja Kühlewind <ietf@kuehlewind.net> Mon, 04 September 2017 13:47 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: curdle@ietf.org
Delivered-To: curdle@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41285132191; Mon, 4 Sep 2017 06:47:46 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kühlewind <ietf@kuehlewind.net>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-curdle-des-des-des-die-die-die@ietf.org, Daniel Migault <daniel.migault@ericsson.com>, curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.59.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150453286625.486.3231906085667027498.idtracker@ietfa.amsl.com>
Date: Mon, 04 Sep 2017 06:47:46 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/kt12YUlOKs8CQPUu-xH0s1ujBOA>
Subject: [Curdle] Mirja Kühlewind's Discuss on draft-ietf-curdle-des-des-des-die-die-die-04: (with DISCUSS)
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 04 Sep 2017 13:47:46 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-curdle-des-des-des-die-die-die-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-curdle-des-des-des-die-die-die/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is mainly a processing question, so probably more for the IESG to discuss
than the authors:

I understand the intention of obsoleting RFC4757 to declare that the algorithms
described should not be used anymore, however, rfc4757 is an informational
implementation description which is probably still deployed. Obsoleting an
informational implementation description seems a bit weird. Just would like to
double-check with the rest of the IESG if that action appropriate...?

Also obsoleting and moving to historic is not the same thing. The document says:
"This document recommends the reclassification of [RFC4757] as Historic."
One of the two actions (obsoleting or moving to historic) is enough. While I
think moving to historic might actually be more appropriate than obsoleting an
implementation description, it should only be moved to historic if this is not
used and deployed anymore. Also moving to historic also requires a status
change action.