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