IETF Logo Mail Archive

Re: [Iasa20] Odd deprecations in draft-ietf-iasa2-consolidated-upd-05

Heather Flanagan <rse@rfc-editor.org> Thu, 21 February 2019 16:41 UTC

Return-Path: <rse@rfc-editor.org>
X-Original-To: iasa20@ietfa.amsl.com
Delivered-To: iasa20@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE0E1286E7 for <iasa20@ietfa.amsl.com>; Thu, 21 Feb 2019 08:41:10 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 KdzdQ1cZfjML for <iasa20@ietfa.amsl.com>; Thu, 21 Feb 2019 08:41:08 -0800 (PST)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582B71228B7 for <iasa20@ietf.org>; Thu, 21 Feb 2019 08:41:08 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 859691C30E8; Thu, 21 Feb 2019 08:40:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHImk6M_5iMZ; Thu, 21 Feb 2019 08:40:55 -0800 (PST)
Received: from [10.198.42.38] (c-71-231-216-10.hsd1.wa.comcast.net [71.231.216.10]) by c8a.amsl.com (Postfix) with ESMTPSA id 236C11C1505; Thu, 21 Feb 2019 08:40:55 -0800 (PST)
From: Heather Flanagan <rse@rfc-editor.org>
Message-Id: <17AB2523-CEB6-4464-8BED-E6B99AFE39A5@rfc-editor.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4243E376-6B0C-45AF-BA72-C771CD7273E2"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 21 Feb 2019 08:41:06 -0800
In-Reply-To: <96A8294B81742974985BE7C8@PSB>
Cc: Russ Housley <housley@vigilsec.com>, IASA 2 WG <iasa20@ietf.org>
To: John C Klensin <john-ietf@jck.com>
References: <1b58312a-ab8e-ccba-2f9b-884091e1c603@nostrum.com> <27724fb0-25ee-0226-b2ee-2b861a34cbf2@gmail.com> <CFBA6F06-E1A6-4974-9BA0-5DCC1CCCA7AE@vigilsec.com> <AF40B5B2002AE7A55B489999@PSB> <051B5D57-4B47-4D29-83CB-9AA3B3E3A6DE@vigilsec.com> <96A8294B81742974985BE7C8@PSB>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/ig1GrIP55XqjAA5qZhX-UkjA_sM>
Subject: Re: [Iasa20] Odd deprecations in draft-ietf-iasa2-consolidated-upd-05
X-BeenThere: iasa20@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: =?iso-8859-1?q?Discussions_relating_to_reorganising_the_IETF_administrative_structures_in_the_so_called_=93IASA_2=2E0=94_project=2E?= <iasa20.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iasa20>, <mailto:iasa20-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iasa20/>
List-Post: <mailto:iasa20@ietf.org>
List-Help: <mailto:iasa20-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iasa20>, <mailto:iasa20-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2019 16:41:10 -0000


> On Feb 16, 2019, at 3:19 PM, John C Klensin <john-ietf@jck.com> wrote:
> 
> That is clearly a mess.   I believe it is the RFC Editor's mess
> and Heather (copied) ought to be able to just figure out a way
> to clean it up and get that implemented.  However I suspect that
> at least one of the IESG, RSOC, or IAB would disagree and think
> they needed to intervene, steer, or at least sign off (I'd be
> delighted to be wrong about that).  It is rather clearly not an
> IASA 2.0 mess or a WG mess except that I think the job of the WG
> is to get the new system and transition documented and to do so
> in a clear and orderly fashion.   I hope we can agree that
> "mess" and "clear and orderly" are inconsistent.

Hi John, all,

This is a long standing mess, and one I brought up with the IESG some time ago. My preference (because I like a human-friendly information trail) is for there to be an RFC that documents (and perhaps explains) the action of moving another to Historic, and that happens sometimes. More often, especially these days, is just a database-level status change, which is considered sufficient by the IESG.

In either case, though, the information is noted on the Info page of the RFC that has been changed to Historic as well as on the RFC Status Change page (https://www.rfc-editor.org/status_changes.php <https://www.rfc-editor.org/status_changes.php>).

Hope that helps,
Heather

v2.8.7 | Report a Bug | By Email