Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-iasa2-rfc7437bis-07: (with DISCUSS and COMMENT)
John C Klensin <john-ietf@jck.com> Tue, 25 June 2019 05:21 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 134B312020A; Mon, 24 Jun 2019 22:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 1VcMsDUpXQq8; Mon, 24 Jun 2019 22:21:29 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.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 59852120058; Mon, 24 Jun 2019 22:21:26 -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 1hfdtT-000POU-3f; Tue, 25 Jun 2019 01:21:23 -0400
Date: Tue, 25 Jun 2019 01:21:17 -0400
From: John C Klensin <john-ietf@jck.com>
To: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>
cc: Jon Peterson <jon.peterson@team.neustar>, iasa20@ietf.org, draft-ietf-iasa2-rfc7437bis@ietf.org, iasa2-chairs@ietf.org
Message-ID: <F398538C7FFBD726780807DD@PSB>
In-Reply-To: <156141779186.17522.6942767062911073521.idtracker@ietfa.amsl.com>
References: <156141779186.17522.6942767062911073521.idtracker@ietfa.amsl.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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/3Mgo03IRuDmrCbhRHWBG7KNY3yk>
Subject: Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-iasa2-rfc7437bis-07: (with DISCUSS and COMMENT)
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: Tue, 25 Jun 2019 05:21:31 -0000
At the risk of tying ourselves in knots, let me add a bit to Barry's comment. As I've commented before, I'm very concerned about this document moving forward while there are outstanding discussions of changes to the recall procedure. If this document replaces 7437 without comment on that subject, then the clear implication is that community consensus has been reached on the subject and we want to leave things as they were in 7437 (and 3777). On the other hand, even had the community wanted to make changes (of the variety proposed in draft-moonesamy-recall-rev or otherwise), it would have been out of scope for the WG. If the I-D had come out of a WG chartered to review the Nomcom and Recall procedures and replace 7437, we presumably would not have allowed the draft to move forward without addressing those outstanding issues and proposals. So let's be clear about what we are doing and avoid making things worse. Note too that, had the scope of the WG been adhered to strictly, the change in terminology from "nominating committee" to "NomCom" (not the community's normal spelling, but that is a separate issue) would be out of scope for the WG. So, perhaps, would miscellaneous editorial changes including some of those that Barry proposes (although, with the exception noted below, I think his suggestions improve the document. Specific suggestions: (1) Clarify scope and coverage. After the first paragraph of Section 1 (the Introduction), add: At the time work was completed on the changes to reflect IASA 2.0, other possible changes to the process specified in RFC 7437 were under discussion in the IETF. This revision addresses only the changes required for IASA 2.0; should the community agree on other changes, they will be addressed in future documents. --On Monday, June 24, 2019 16:09 -0700 Barry Leiba via Datatracker <noreply@ietf.org> wrote: >... > — Section 4.14 — > > Members of the IETF community must have attended at least > three of the last five IETF meetings in order to volunteer. > > I hesitate to say this, given other ongoing discussions, but > "attended at least three of the last five IETF meetings in > person in order to volunteer" has to be clear here, > especially as we now have formal registration for remote > participants. (2) The hesitation is, IMO, appropriate. Changes and clarifications to the procedures that are unrelated to IASA 2.0, especially substantive ones (which that is) are either out of scope or they are not. If they are not in scope, then the IESG making a change that the WG was not allowed to make seems highly inappropriate. >... > — Sections 7.1.1 and 7.1.2 — > The way these are written makes it sound as if a Recall > Committee Chair is appointed only for an Ombudsteam-initiated > recall and not in the case of a community petition. Here's > what I suggest: As Section 7.1 already says that recalls > initiated by the Ombudsteam follow 7776, there's no need to > say it again in 7.1.2. So how about this?: > > OLD > The Ombudsteam process allows the Ombudsteam to form a > recall petition on its own without requiring 20 signatories > from the community. As defined in [RFC7776], the petition > and its signatories (the Ombudsteam) shall be announced to > the IETF community, and a Recall Committee Chair shall be > appointed to complete the Recall Committee process. It is > expected that the Recall Committee will receive a briefing > from the Ombudsteam explaining why recall is considered an > appropriate remedy. > NEW > The Ombudsteam process allows the Ombudsteam to form a > recall petition on its own without requiring 20 signatories > from the community. The petition and its signatories (the > Ombudsteam) shall be announced to the IETF community, as > with a community petition, and it is expected that the > Recall Committee (see below) will receive a briefing from > the Ombudsteam explaining why recall is considered an > appropriate remedy. > END (3) I think that, given the introductory paragraph of Section 7.1, this is overkill and will add to the confusion. Alternate suggestion: (3.1) Replace the introductory paragraph of Section 7.1, which is the real source of the confusion, with: The recall process is initiated with a signed petition submitted to the Internet Society President. The petition may submitted at any time to request the recall of any sitting IESG or IAB member, or NomCom appointed IETF Trust Trustee, or NomCom appointed IETF LLC Director. There are two different types of petitions with different requirements as discussed in the two subsections below. Given the listing in the second paragraph of the introduction to Section 7 ("applies to IESG and IAB Members, the NomCom appointed IETF Trust Trustees, and the NomCom appointed IETF LLC Directors."), it is not clear to me that repeating that list in the above is helpful although, if it is removed and "sitting" is really needed, that terminology should be moved to the Section introduction. Then 7.1.2 becomes: The Ombudsteam process allows the Ombudsteam to form a recall petition, i.e., to initiate the recall process, on its own rather than going through the procedure in the previous section. The petition and its source (the Ombudsteam) shall be announced to the IETF community, as with a community petition, and it is expected that the Recall Committee (see below) will receive a briefing from the Ombudsteam explaining why recall is considered an appropriate remedy. By removing details like "20 signatures" from the above, we cause no harm if that number is permanent but reduce the need to look through the document to find and correct stray and redundant comments should changes be made in the future. > Then we let 7.2 et seq explain the common parts of the recall > process, including appointment of the Recall Committee Chair. Yes. >... > — Section 7.3 — > More number disagreement (plural subject and "a member"). > > NEW > The recall committee is created according to the same rules > as is the NomCom, with the qualification that both the > person being investigated and the parties requesting the > recall must not be involved in the recall committee in any > capacity. > END Probably out of scope, but I just realized I can't find a rule that prohibits someone from simultaneously serving on a NomCom and on a Recall Committee. best, john
- [Iasa20] Barry Leiba's Discuss on draft-ietf-iasa… Barry Leiba via Datatracker
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… John C Klensin
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- 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-… Barry Leiba
- 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-… Bob Hinden
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… John C Klensin
- 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-… Barry Leiba
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- 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
- 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-… Barry Leiba
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Livingood, Jason
- [Iasa20] WGs and scope restrictions (was: Re: Bar… John C Klensin
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Barry Leiba
- Re: [Iasa20] Barry Leiba's Discuss on draft-ietf-… Bob Hinden