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