Re: [Iasa20] draft-ietf-iasa2-consolidated-upd-06

John C Klensin <john-ietf@jck.com> Fri, 08 March 2019 00:56 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 559691310E9 for <iasa20@ietfa.amsl.com>; Thu, 7 Mar 2019 16:56:41 -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, 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 URmCONK1vxfo for <iasa20@ietfa.amsl.com>; Thu, 7 Mar 2019 16:56:39 -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 E3D891310D7 for <iasa20@ietf.org>; Thu, 7 Mar 2019 16:56:38 -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 1h23oR-0009yl-VJ; Thu, 07 Mar 2019 19:56:35 -0500
Date: Thu, 07 Mar 2019 19:56:30 -0500
From: John C Klensin <john-ietf@jck.com>
To: Alissa Cooper <alissa@cooperw.in>, Brian E Carpenter <brian.e.carpenter@gmail.com>
cc: iasa20@ietf.org
Message-ID: <CD6FB2CD65EAEA39265FFD0F@PSB>
In-Reply-To: <3AC01BB5-613D-474C-B8AE-A85D8F264A83@cooperw.in>
References: <A7B72177ABB2B2F0BEE7763B@PSB> <567462F2-46E3-445E-BDA3-493DA7AD31CC@cooperw.in> <4faec579-e4dd-f138-4c96-f26d9945c307@gmail.com> <3AC01BB5-613D-474C-B8AE-A85D8F264A83@cooperw.in>
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/BKX03w2BIWyPi3UmSOWafOTgHXw>
Subject: Re: [Iasa20] draft-ietf-iasa2-consolidated-upd-06
X-BeenThere: iasa20@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions relating to reorganising the IETF administrative structures in the so called “IASA 2.0” project. <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: Fri, 08 Mar 2019 00:56:41 -0000


--On Thursday, March 7, 2019 16:52 -0500 Alissa Cooper
<alissa@cooperw.in> wrote:

> Hi Brian,
> 
>> On Mar 7, 2019, at 2:46 PM, Brian E Carpenter
>> <brian.e.carpenter@gmail.com> wrote:
>> 
>> On 08-Mar-19 06:12, Alissa Cooper wrote:
>>> Thanks. I still don't think this is quite right because
>>> there is no basis for this working group to obsolete or
>>> render historic RFC 3929 simply because it mentions the IETF
>>> Executive Director. It seems that RFC 3929 should be treated
>>> in Section 2 the same as the other documents in that section.
>> 
>> There's a more general issue: tracking down all "open"
>> Experimental RFCs and deciding which of them need to be
>> closed off as Historic or Obsolete or both. <joke>No doubt
>> the IESG will be doing this in its copious free time.</joke>
>> But for the present, doesn't it make more sense to clear both
>> 3929 and 4633 up right away? I agree that it's outside the
>> WG's mandate, strictly interpreted, but if the IESG consents,
>> is that really a problem?
> 
> Yes. The point of charters is to scope working groups' work.
> This working group is chartered to to document the normative
> changes to IETF administrative structures and processes
> necessary to effectuate the change to IASA 2.0. Obsoleting
> documents about other things because they are out of date is
> not within the charter.

Alissa,

I was in the process of putting together a discussion of the
IETF's history with making things Historic and then Brian's note
arrived and I concluded that maybe I was missing your main point
and I discarded that note.  We may have a small difference of
opinion about what it means to "scope working groups' work",
which I want to try to summarize below.

However, I, and I assume most WG participants, am much more
interested in getting this work finished than in arguing so, if
you are putting on your Responsible AD hat and telling me to
change this, I will certainly do so.

To me, there are two closely-related principles for charters and
limits on the scope of a WG's work:

(1) To be sure enough that the community is aware of what the WG
is doing so that IETF participants who are skilled in the topic
area(s) and materially concerned can either participate or
otherwise follow the WG's efforts and, in particular, are not
blindsided at IETF LC time or later.

(2) To lower the odds that the WG will go off in the weeds in a
major way, in particular by exceeding its competence and/or
taking up time that detracts from the overall planned schedule
or other tasks, and giving people who believe it is doing that a
basis for raising objections.

However, I think it is also important to keep some perspective
and flexibility on charters and scope if those principles are
not grossly violated.  One of the hallmarks of the IETF (and the
network specification development mechanisms long before it) has
been that it is far more important to get the right things to
happen and get the right things done than to go looking for
rules to interpret and enforce narrowly.  Some of us have even
argued in other contexts that, in addition to technical
advantages, much of the reason why the core technology for
modern networking is TCP/IP and related protocols as specified
by the IETF and its predecessor rather than, e.g., OSI, is
precisely that focus on getting the right things done rather
that spending disproportionate energy figuring out the letter of
the are and enforcing them.

So, in this particular case, the WG, working well within its
scope, discovered some now-problematic phrasing in 3929.   In
the process of figuring out how to fix that, it was observed
that the document was almost certainly no longer relevant.  The
conclusion, as I understood it, was that getting it off the list
of things that people were expected to read and understand would
be a more efficient fix than patching a phrase in a seriously
old document and perhaps creating confusion about whether the
specified experiment was still alive and relevant.  That is not
exceeding the WG's task area or competence, because almost
anyone could spot the relative obsolescence of the spec and the
problem was discovered in the process of doing the WG's work.
It didn't take extra time or effort.  Ted (the author), who
appears to be following the WG's work, didn't stand up and say
"no, no, that experiment is still active and the document is
still alive" and neither did anyone else.  I assume any such
substantive objection would have immediately killed the "make
Historic" plan.

So, yes, the decision could be to just patch the document
because making it Historic is not strictly within the WG's scope
but I don't see any possible harm that could result from just
getting 3929 off everyone's radar and out of the way.   In
addition, now that the problem has been identified and with a
nod to Brian's joke, do you really want to either get a request
for a WG or an individual submission to make 3929 Historic?
While I certainly would not want to advocate a hunting
expedition to identify and consider all of outstanding
Experimental documents and figure out which ones should be
Historic and/or Obsolete, in this case, the hard work of
identifying a relevant document and even writing an appropriate
sentence has been done already.

best,
    john