Re: [Iasa20] Odd deprecations in draft-ietf-iasa2-consolidated-upd-05
John C Klensin <john-ietf@jck.com> Sat, 16 February 2019 23:19 UTC
Return-Path: <john-ietf@jck.com>
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 D22DD1200D7
for <iasa20@ietfa.amsl.com>; Sat, 16 Feb 2019 15:19:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 p-LgoyRCyiFF for <iasa20@ietfa.amsl.com>;
Sat, 16 Feb 2019 15:19:55 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 0AD43129BBF
for <iasa20@ietf.org>; Sat, 16 Feb 2019 15:19:55 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB)
by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD))
(envelope-from <john-ietf@jck.com>)
id 1gv9FP-0007qx-NY; Sat, 16 Feb 2019 18:19:51 -0500
Date: Sat, 16 Feb 2019 18:19:46 -0500
From: John C Klensin <john-ietf@jck.com>
To: Russ Housley <housley@vigilsec.com>
cc: IASA 2 WG <iasa20@ietf.org>, rse@rfc-editor.org
Message-ID: <96A8294B81742974985BE7C8@PSB>
In-Reply-To: <051B5D57-4B47-4D29-83CB-9AA3B3E3A6DE@vigilsec.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>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/ArT7X--hV0buohvxg_RG3JlAo90>
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: Sat, 16 Feb 2019 23:19:57 -0000
--On Friday, February 15, 2019 12:17 -0500 Russ Housley <housley@vigilsec.com> wrote: >... >> See Brian's note(s) but the above reasoning suggests that its >> getting sucked in was and is appropriate, at least unless the >> IESG wants to move, now, to make 3716 Historic. > > I have no problem with RFC 3716 being moved to historic, but > that should not happen as part of the IASA2 effort. Russ, I prefer that the IESG handle that separately so we are, up to that point, in sync. I also agree with Alissa that this "consolidated" document should not be obsoleting most or all of those old pieces, but should be moving them to historic. The problem with the latter is that I was trying to leave an information chain. We don't seem to have either headers on RFCs or even tracking information in RFC metadata about what documents or actions resulted in something else becoming Historic so, if one finds the older document, discovers that it is no longer relevant, and tries to trace forward to what is, that process is much harder than it should be unless the older document is also obsoleted. 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. Beyond that, I'm back to the disclaimer in my earlier note. "Obsoleted" and "Historic" are in this I-D because the WG co-chairs told me to put them in and because no one has raised any objections up to this point. If I get clear instructions to do something different, I will make the changes and hope we are converging. I will complain if we lose the tracks/ footprints, but I'm prepared to be in the rough. > Side note: Using "Executive Director" has already made this > way more complicated that had we chosen other synonyms that > were available before the LLC was stood up. A nearly identical observation was that the changed/ reused title was what first caused a number of new (replacement/ obsoleting) documents to be created just to retune titles and then the present I-D to be started to eliminate the need for all of those separate documents and to be more clear about what was actually being changed (titles rather than anything substantive in most cases). When that was brought up, my recollection is that we were told that the lawyers liked "Executive Director", wrote it into the LLC agreement, and that we were stuck with it. My enthusiasm for that way of doing business in a supposedly bottom-up, consensus-based IETF is apparently worth less than the proverbial cup of coffee and suggestions that we use a different set of titles informally but consistently and document them in one place got absolutely zero traction, so I'm trying to make the best of what I consider a very bad situation. But yes, at least in retrospect, I think "way more complicated than it needed to be" may be something of an understatement. best, john
- [Iasa20] Odd deprecations in draft-ietf-iasa2-con… Robert Sparks
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… Brian E Carpenter
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… Robert Sparks
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… Russ Housley
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… Ted Hardie
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… Brian E Carpenter
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… Brian E Carpenter
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… John C Klensin
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… Russ Housley
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… Alissa Cooper
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… John C Klensin
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… Russ Housley
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… John C Klensin
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… Heather Flanagan
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… Livingood, Jason
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… Eliot Lear
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… John C Klensin
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… Eliot Lear
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… Alissa Cooper
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… John C Klensin
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… Ted Hardie
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… John C Klensin
- Re: [Iasa20] Odd deprecations in draft-ietf-iasa2… Alissa Cooper