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.
- [Iasa20] Barry Leiba's Discuss on draft-ietf-iasa… Barry Leiba via Datatracker
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Ted Hardie
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Russ Housley
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Ted Hardie
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Bob Hinden
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Mirja Kuehlewind
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Joseph Lorenzo Hall
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Russ Housley
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Ted Hardie
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… John C Klensin
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Alissa Cooper
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… John Levine
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Ted Hardie
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Brian E Carpenter
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Mirja Kuehlewind
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Joseph Lorenzo Hall
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Joseph Lorenzo Hall
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Ted Hardie
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… John Levine
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… John C Klensin
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Bob Hinden
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Joseph Lorenzo Hall
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Alissa Cooper
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Joseph Lorenzo Hall
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Brian E Carpenter
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Joseph Lorenzo Hall
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Alissa Cooper
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Brian E Carpenter
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… John C Klensin
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Joseph Lorenzo Hall
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Alissa Cooper
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… John C Klensin
- [Iasa20] Recall details in rfc7437bis Alissa Cooper
- Re: [Iasa20] Recall details in rfc7437bis John C Klensin
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- Re: [Iasa20] Recall details in rfc7437bis Brian E Carpenter
- Re: [Iasa20] Recall details in rfc7437bis Adrian Farrel
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Joseph Lorenzo Hall
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Joseph Lorenzo Hall
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… John C Klensin
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Joseph Lorenzo Hall
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Joseph Lorenzo Hall