Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-iasa2-rfc4071bis-08: (with DISCUSS and COMMENT)

John C Klensin <john-ietf@jck.com> Mon, 08 April 2019 18:28 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 AFA681201E6; Mon, 8 Apr 2019 11:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 nq0xBTSsxWLj; Mon, 8 Apr 2019 11:28:51 -0700 (PDT)
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 22376120174; Mon, 8 Apr 2019 11:28:51 -0700 (PDT)
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 1hDZ0h-000PYL-En; Mon, 08 Apr 2019 14:28:47 -0400
Date: Mon, 08 Apr 2019 14:28:42 -0400
From: John C Klensin <john-ietf@jck.com>
To: Ted Hardie <ted.ietf@gmail.com>, Russ Housley <housley@vigilsec.com>
cc: draft-ietf-iasa2-rfc4071bis@ietf.org, Jon Peterson <jon.peterson@neustar.biz>, IASA 2 WG <iasa20@ietf.org>, iasa2-chairs@ietf.org, IESG <iesg@ietf.org>, Barry Leiba <barryleiba@computer.org>
Message-ID: <8368BB51061BE803C3BF25B0@PSB>
In-Reply-To: <CA+9kkMBNVEFZQWO8c8g2AARZ7xidZLYGF1BhJnXvULkzrPBkSA@mail.gmail.com>
References: <155470226964.18209.2289908384768506570.idtracker@ietfa.amsl.com> <CA+9kkMB40Op1igA4emnkB=XWdj7ZzuUrK_5nTWBnW928FVW9pg@mail.gmail.c om> <0B892B67-6402-4898-A041-C232CA4A2E35@vigilsec.com> <CA+9kkMBNVEFZQWO8c8g2AARZ7xidZLYGF1BhJnXvULkzrPBkSA@mail.gmail.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/eVNbPpVQ_zv7XFuStpVHF3iDbqc>
Subject: Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-iasa2-rfc4071bis-08: (with DISCUSS and COMMENT)
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: Mon, 08 Apr 2019 18:28:54 -0000


--On Monday, April 8, 2019 10:01 -0700 Ted Hardie
<ted.ietf@gmail.com> wrote:

>...
> But shifting that often would be terrible for the Board.  As
> it stands, there's a lot of context in all of this and that
> amount of transition is just bad for forward progress.  Since
> this appointee has to act on behalf of the whole organization
> (as all board members do), having them have less context than
> the other members is already bad; shifting to one year would
> make it potentially much worse.  I think that would make this
> much closer to a liaison role, with all the issues that
> entails.
> 
> I believe Barry's DISCUSS was "was this choice made
> deliberately?" and the answer to that is clear: yes.  We could
> take this as a signal to re-litigate it, but that is not the
> point of the IESG review and would not be an appropriate
> reaction to this DISCUSS.  That would, in fact, shift it over
> the line in the DISCUSS criteria document to DISCUSS
> non-criteria:
> 
> Disagreement with informed WG decisions that do not exhibit
> problems outlined in Section 3.1 (DISCUSS Criteria)
> <https://www.ietf.org/blog/discuss-criteria-iesg-review/#stand
> -disc>. In other words, disagreement in preferences among
> technically sound approaches.

Ted,

I don't know how strongly I feel about this, especially because
it has been well over a decade since I've had experience with
the internal workings of the IESG, however...

(1) As I tried to point out several times on the WG list, while
this, and several other issues, were discussed within the WG,
virtually all of the discussions involved a very small number of
people, people with a great deal in common even when they
disagree.  Under similar circumstances, even if the WG's
consensus is representative of the intersection of all IETF
participants who care about such issues and those who have
sufficient (day job or other) time and other resources to
participate actively in the work, it is a large step to get from
there to the kind of "informed WG decision" that should set a
very high bar for issues to be raised during IETF LC or
subsequent IESG review.

(2) It is always a bit problematic to apply criteria designed
for technical specifications (including the subsection you cite
which I note is part of a section titled "Protocol Action
Criteria" -- and approval or disapproval of this action is not,
technically, a Protocol Action) to IETF procedural
specifications.  However, it seems to me that, even with the
language in Section 3.1 to which the material you cite from
Section 3.2 refers, the last bullet of 3.1, which starts "The
IETF as a whole does not have consensus on the technical
approach or document", provides sufficient procedural
justification for raising the question that Barry raised.

(3) If we can step past the procedure-lawyering, it seems to me
that the situation here involves a non-trivial tradeoff between
maximum efficiency and continuity of the IETT LLC Board (which
argues for longer terms and probably for more, rather than
fewer, ex-officio positions) and for allowing the IESG to
maximize its own efficiency and effectiveness in carrying out
its many responsibilities to the community.  

Personally, I think the latter is more important because I
believe that, if the importance of the LLC comes to dominate how
the IESG organizes itself or the criteria the Nomcom is expected
to use in selecting IESG members, we will have done a rather
good job of shooting ourselves in our collective feet.  YMMD
about that, of course.  Similarly, I believe that piling more
and more responsibilities onto the IETF Chair position
ultimately weakens the IETF by narrowing the range of people who
can assume that position to those who are supported by
organizations with the resources and will to provide people with
full-time, or nearly full-time, to the IETF.   All other things
being equal, I'd rather provide IETF Chair appointees and the
IESG the flexibility to make appropriate adjustments for
available time, expertise, and other priorities.

As far as "re-litigating" [1] these issues, I suggest that,
while much of the above was mentioned during the WG discussions,
the topics were largely dismissed, not because of any bed
behavior on the part of WG leadership but because there was no
evidence that any of that fairly narrow group of active
participants wanted to engage on them.  We've been clear in
other contexts that one cannot determine IETF (or WG) consensus
by saying something and noticing that no one speaks up; I
suggest that is much closer to what happened here.

best,
   john

[1] I am trying to figure out when and where the notion of
litigating (or re-litigating) a particular decision entered into
the IETF vocabulary but, if we are going to keep repeating
phrases about Kings, rough consensus, etc., as our fundamental
principles, I suggest we try to get rid of it.   The kind of
legal or judicial proceeding the terms implies is completely out
of place here unless we are setting specific people up as judges
or with imperial power.  I hope no one here, especially those
whose positions might make them candidates for such roles,
actually wants that.