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

Alissa Cooper <alissa@cooperw.in> Fri, 28 June 2019 14:24 UTC

Return-Path: <alissa@cooperw.in>
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 52013120300; Fri, 28 Jun 2019 07:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.69
X-Spam-Level:
X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=QLbE+eAC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=M828aEc6
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 xWX-mZyJWd_4; Fri, 28 Jun 2019 07:24:40 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C151202EA; Fri, 28 Jun 2019 07:24:33 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id CCFC32015D; Fri, 28 Jun 2019 10:24:32 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 28 Jun 2019 10:24:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=b CKPH0hbAdjULlf//In2/8mFlqISUxQqQrSaj5TkzOg=; b=QLbE+eACqNrF7GlQq FgLBSBl6NfqWSczZjKAZJXR5F4JTcU0nReL+YUBjGLe03Chiq8GgF/qhXfaN8puT 4rCjzWGOgdQ6K2vgGNtXqk7HpE0gbSv0uZ4ANb0o5bsfRBFC3ZtWeN0swqZ9AKTi 3WofbXgSr+FC0DUl4hDCLftPQEQiEOGB9wn+jqArGWJzeSdbTh1bVkalg7+KjIAJ bYCPFB3rYVswDR3zyKrCHuVKeE0do76Mh93T8Plto6Ty4i3jaKWFZW/L4h083SOQ 2fXj2L9JBAl5dbAh6F2iGbMALFgSxqkOgNlbOoDO/AFgJPg5e+uZmg8N58499gFq 1k1Ig==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=bCKPH0hbAdjULlf//In2/8mFlqISUxQqQrSaj5Tkz Og=; b=M828aEc6DY3JFmml2cW7rFL2XgF/fkVzCCYYC2fgCbMw7kCUmoZWqqHQF G+rVClkvdR1Vlm2P97WBB/QXetk6CG0hoL9gHaGIEj1BHK8KvMxMC2QDJbHJpkmR C316/K3UydhkQ9AfpFtsSJX+aB9u3E8BYiGoEq9F1skFyML+MHLDwxzkmtNrM3au kWex+1hUhynQdYI/qb3voiZBhvttdLvTRsGV7q4s5E3RaHmp58ASq9oI405ifwcW GFZ7b77vpmZtE+dEboNo4x++6CEIdXt+WY01U5C13rBDbej0iKnNd3PSoX9D8EhR J10WaB5VaaRSFVjRy062UP4Sxak/g==
X-ME-Sender: <xms:ICMWXbysSC5avGBcRmAhLD3xnO86Xl-D8z3h9slOzUlhHLDjtQceKQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrvddtgdejkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdelvdenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt
X-ME-Proxy: <xmx:ICMWXUB95YauBUdcW2PNKxaHKfFhoZM-vQDcIVrXqtHoqR4r324_ug> <xmx:ICMWXeMDA8OymVF1H7FUpQP3MYmmj19r9PFFDro8hZY4YbLgm4NA0Q> <xmx:ICMWXdYvqXI3dMxNB7IZo8B7PJdaB9haiXDa5BAJ2lMMA8lzTtfCjg> <xmx:ICMWXZ640-ihWsD5h8JodISC4t2522tbjuSEHs3KlVLK89vlBMTOrA>
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.92]) by mail.messagingengine.com (Postfix) with ESMTPA id 8D4E8380083; Fri, 28 Jun 2019 10:24:31 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <156141779186.17522.6942767062911073521.idtracker@ietfa.amsl.com>
Date: Fri, 28 Jun 2019 10:24:29 -0400
Cc: IESG <iesg@ietf.org>, Jon Peterson <jon.peterson@team.neustar>, IASA 2 WG <iasa20@ietf.org>, draft-ietf-iasa2-rfc7437bis@ietf.org, iasa2-chairs@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1C131171-0ABE-4DB1-BEB7-03E765B1E6C6@cooperw.in>
References: <156141779186.17522.6942767062911073521.idtracker@ietfa.amsl.com>
To: Barry Leiba <barryleiba@computer.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/iasa20/hYduopXSJHVzn7z5jw90XIoscKQ>
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: Fri, 28 Jun 2019 14:24:44 -0000

Hi Barry,

> On Jun 24, 2019, at 7:09 PM, Barry Leiba via Datatracker <noreply@ietf.org> wrote:
> 
> Barry Leiba has entered the following ballot position for
> draft-ietf-iasa2-rfc7437bis-07: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-iasa2-rfc7437bis/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Thanks for the work on this!
> 
> I have three points I'd like to discuss, all of which should be easy:
> 
> — Section 3.8 —
> 
>   However, the following exception is permitted in the case where the
>   candidate for an open position is currently a sitting member of the
>   IAB.  It is consistent with these rules for the announcements of a
>   resignation of a sitting member of the IAB and of the confirmed
>   candidate for the mid-term vacancy created by that sitting member on
>   the IAB to all occur at the same time as long as the actual sequence
>   of events that occurred did so in the following order:
> 
>   1.  The NomCom completes the advice and consent process for the open
>       position being filled by the candidate currently sitting on the
>       IAB.
> 
>   2.  The newly confirmed candidate resigns from their current position
>       on the IAB.
> 
>   3.  The IAB Chair (or the Managing Director, IETF Secretariat, if no
>       Chair has been named or the vacancy was created via the departure
>       of the IAB Chair) informs the NomCom of the mid-term vacancy.
> 
>   4.  The NomCom acts on the request to fill the mid-term vacancy.
> 
> Either I don’t understand what this is saying or I don’t understand how it’s
> possible.  Paraphrasing, the first paragraph says that it’s OK for the
> announcement of the sitting IAB member’s resignation to happen at the same time
> as the announcement of that member’s confirmed replacement.  That means that at
> the time of the resignation, the NomCom already had to have selected the
> replacement, given that selection to the confirming body, and had it confirmed.
> Which means that step 4 had to have happened before step 2, or at least before
> step 3, no?
> 
> — Section 4.6 —
> 
>   Any such appointment must be temporary and does not absolve the Chair
>   of any or all responsibility for ensuring the NomCom completes its
>   assigned duties in a timely fashion.
> 
> Then where does it say how to permanently replace a NomCom Chair who really
> does have to leave permanently (say, death or incapacity, unexpected family
> issues, or even just is no longer willing to do it)?
> 
> — Section 4.10 —
> 
>   The prior year's Chair may select a designee from a pool composed of
>   the voting volunteers of the prior year's committee and all prior
>   Chairs if the Chair is unavailable.  If the prior year's Chair is
>   unavailable or is unable or unwilling to make such a designation in a
>   timely fashion, the Chair of the current year's committee may select
>   a designee in consultation with the Internet Society President.
> 
> Why is it that the prior year’s Chair can pick someone else on her own, but the
> current Chair has to consult with the ISOC President to do the same thing?

Bob has added the following text to the -08 version of the document:

"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.”

The authors and the WG have been strict about only applying changes necessary for IASA 2.0, so while clarifying the points you raise above may be useful for a future update, they are not in scope for this one.

Thanks,
Alissa

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> There are a lot of comments here, but they're basically all editorial.
> 
> General: While it’s not necessary, it would be helpful if the many places that
> say “elsewhere in this document” had internal section-number citations instead.
> 
> — Abstract —
> The abstract says that it’s “based on RFC3777 and RFC7437”, but 3777 was
> obsoleted by 7437.  Does it really make sense to mention 3777 in the Abstract? 
> I think it isn’t, and suggest:
> 
> OLD
>   This document
>   is based on RFC3777 and RFC7437 and has been updated to reflect the
>   changes introduced by IASA 2.0.
> NEW
>   This document
>   is based on and replaces RFC7437, and has been updated to reflect
>   the changes introduced by IASA 2.0.
> END
> 
> — Introduction —
> Here I think it’s worth mentioning 3777 as part of the history, but “updates”
> isn’t strong enough for clarity.  Perhaps:
> 
> OLD
>   This document is a revision of [RFC7437] that updates it to be
>   consistent with the IASA 2.0 changes.  RFC 7437 was based on
>   [RFC3777] that consolidated and updated other RFCs that updated that
>   document into a single specification.  The result is a complete
>   specification of the process by which members of the Internet
>   Architecture Board (IAB) and Internet Engineering Steering Group
>   (IESG), some Trustees of the IETF Trust, and some Directors of the
>   IETF Administration LLC (IETF LLC), are selected, confirmed, and
>   recalled.
> NEW
>   This document is a revision of [RFC7437] that updates and replaces
>   it, and is consistent with the IASA 2.0 changes.  RFC 7437 was based
>   on [RFC3777] and its updates, and consolidated and updated the process
>   into a single specification at that time.  This document is now the
>   sole and complete specification of the process by which members of the
>   Internet Architecture Board (IAB) and Internet Engineering Steering Group
>   (IESG), some Trustees of the IETF Trust, and some Directors of the
>   IETF Administration LLC (IETF LLC), are selected, confirmed, and
>   recalled.
> END
> 
> Does that work?
> 
> I do wish we could avoid “IETF Trust Trustees”, but that ship has
> <trike>sunk</strike> sailed.
> 
> We use “IETF LLC Director” (3 times) and “IETF LLC Board Director” (6 times)
> interchangeably; we should pick one and use it consistently.
> 
> — Section 3.1 (and 4.6 and 5.6) —
> 
> Nit: The word “comprised” is correctly used as “the whole comprises its parts”,
> and is used correctly in Section 4.3.  It’s used in the document three times
> incorrectly (“the whole is comprised of its parts”, for which the correct word
> is “composed”).  Please change the three instances of “is comprised of” either
> to “is composed of” or “comprises” (I prefer the latter).
> 
> — Section 3.2 —
> 
>   The principal functions of the NomCom are to review each open IESG,
>   IAB, IETF Trust, and IETF LLC Board position and to nominate either
>   its incumbent or a superior candidate.
> 
> As “nominee” is defined as someone being considered by the NomCom, and
> “candidate” is the one selected, this should say “and to select”, not “and to
> nominate”.
> 
> Similarly for “candidate that is nominated” in the fourth paragraph and “to
> which he or she is nominated” in the last paragraph. (Note that “nominated”
> *is* correct in the fifth paragraph.)
> 
> — Section 3.3 —
> 
>   or if a member or Director unexpectedly resigns.
> 
> “if a member, a Director, or a Trustee” (and similarly in the middle of Section
> 3.4)
> 
> — Section 3.4 —
> 
>   Confirmed IETF LLC Board Director candidates are expected to serve at
>   least a three-year term, except if a nominating or selection body
>   decides to use a shorter term to allow for initial staggered
>   appointments.
> 
> Given that the initial staggered appointments have already been made, the
> “except” part seems overtaken by events.  Does it really make sense to publish
> that now, especially as the reference in the following sentence covers that
> situation?  (And similarly for the next paragraph about Trustees.)
> 
> For all three paragraphs, “a three year term” doesn’t match “candidates” in
> number.  I suggest making them both singular, so “A confirmed IESG or IAB
> candidate is expected to serve at least a two-year term.”  And similarly for
> the other two.  Alternatively, we could change “a two-year term” to “two-year
> terms”, making them both plural.
> 
> In both the Director and Trustee paragraphs, “additional guidance on terms
> length” should say “term length”.
> 
>   The term of a confirmed candidate selected according to the mid-term
>   vacancy rules may be less than a full term (two years for IESG and
>   IAB, three years for the IETF Trust and IETF LLC), as stated
>   elsewhere in this document.
> 
> Why repeat the term length here?  I would remove the parenthesized bit.
> 
>   For confirmed candidates of the IESG, the terms begin no later than
>   when the currently sitting members' terms end on the last day of the
>   meeting.  A term may begin or end no sooner than the first day of the
>   meeting and no later than the last day of the meeting as determined
> 
> This seems like an editing error.  I would merge the two sentences:
> 
> NEW
>   For the IESG, the term of the sitting member ends and the term of the
>   confirmed candidate begins no sooner than the first day of the meeting
>   and no later than the last day of the meeting as determined
> END
> 
>   For candidates confirmed under the mid-term vacancy rules, the term
>   begins as soon as possible after the confirmation.
> 
> I would say “as soon as practicable”.  It’s quite possible that it would be
> *possible* to begin a term, but there could be reasons to wait a bit.
> 
> — Section 3.5 —
> 
>   1.  When there is only one official NomCom, the body with the mid-
>       term vacancy relegates the responsibility to fill the vacancy
> 
> While “relegates” *can* mean “delegates”, the general sense of “relegate” is
> negative ("We relegated it to the trash pile.").  Better to use “delegates”, or
> simply “gives”.  (Twice in this paragraph and once in Section 4.2.)
> 
>   4.  The term of the confirmed candidate will be either:
> 
>       A.  the remainder of the term of the open position if that
>           remainder is not less than one year or
> 
>       B.  the remainder of the term of the open position plus the next
>           two-year term if that remainder is less than one year.
> 
> This is clearly written for the IAB and IESG, and hasn’t been changed to
> account for Directors and Trustees.
> 
> — Section 3.6 —
> 
>   The NomCom and confirming body members will be exposed to
>   confidential information as a result of their deliberations, their
>   interactions with those they consult, and from those who provide
>   requested supporting information.
> 
> The list is not parallel (the third item doesn’t work).
> 
> NEW
>   The NomCom and confirming body members will be exposed to
>   confidential information as a result of their deliberations and
>   their interactions with those they consult, and from those who
>   provide requested supporting information.
> END
> 
>   The NomCom
>   may disclose a list of names of nominees who are willing to be
>   considered for positions under review to the community
> 
> “under review to the community” reads funny.  I would move “to the community”
> to be after “list of names”.
> 
> — Section 3.7.3 —
> 
>   The sitting IESG members review the IETF Trust Trustee Candidates.
> 
> There should be only one (as with the Board candidate in the next paragraph),
> and it shouldn’t be capitalized.
> 
>   The confirming bodies conduct their review using all information
> 
> Their “reviews”, plural.
> 
>   and the confirming bodies' interpretation
> 
> The bodies’ “interpretations”, plural.
> 
>   the NomCom must select alternate candidates for the rejected
>   candidates.
> 
> “alternative” candidates.
> 
> — Section 4.1 —
> 
>   The completion of the selection and organization process is due at
>   least one month prior to the Third IETF.  This ensures the NomCom is
>   fully operational and available for interviews and consultation
>   during the Third IETF.
> 
> As selection is normally done prior to the *Second* IETF now, is it worth
> saying that (not requiring it; the requirement as stated is fine)?  Something
> like, “In practice, the selection process is generally completed prior to the
> Second IETF, so that the Second IETF can be used for organization.”  I think
> it’s especially important to say this because otherwise it seems like the old
> and new NomComs are only required to overlap by one month, and Section 4.2 says
> they’re meant to overlap for “approximately three months”.
> 
> — Section 4.2 —
> 
>   When the prior year's NomCom is filling a mid-term vacancy during the
>   period of time that the terms overlap, the NomCom operate
>   independently.
> 
> “NomComs”, plural.
> 
> — Section 4.8 —
> This section doesn’t say anything about liaison appointment from the ISOC BoT;
> it probably should.
> 
> — Section 4.10 —
> 
>   The prior year's Chair may select a designee from a pool composed of
>   the voting volunteers of the prior year's committee and all prior
>   Chairs if the Chair is unavailable.
> 
> For clarity, “if the prior year’s Chair is unavailable,” because there are two
> Chairs under discussion.
> 
> — 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.
> 
>   Volunteers must provide their full name, email address, and primary
>   company or organization affiliation (if any) when volunteering.
> 
> Hm, number-agreement problem (plural volunteers and singular name, etc.), but
> it’s sticky to fix it and keep it gender-free.  We could go with the custom of
> using “their” as gender-free singular and say, “Each volunteer must provide
> their full name….”  Or we could make it all plural (which I think I like a tad
> better):
> 
> NEW
>   Volunteers must provide their full names, email addresses, and
>   primary company or organization affiliations (if any) when
>   volunteering.
> END
> 
> — Section 4.16 —
> 
>   The pool of volunteers must be enumerated or otherwise indicated
>   according to the needs of the selection method to be used.
> 
> Maybe “otherwise annotated”?  “Indicated” doesn’t seem like the right word.
> 
> — Section 4.17 —
> 
>   the same affiliation, then the volunteer should notify the Chair who
>   will determine the appropriate action.
> 
> Comma before “who”, please.
> 
>   During at least the one week challenge period, the Chair must contact
> 
> What does that mean?  Is it meant to mean “during the challenge period, which
> is a least one week”?  If so, just say “During the challenge period,” as the
> one week length has already been stated. If it means something else, what?
> 
> — Section 4.18 —
> 
>   The Chair works with the members of the committee to organize itself
>   in preparation for completing its assigned duties.
> 
> I don’t think “itself” works here.  I’d say, “The Chair works with the NomCom
> members to organize the committee….”
> 
> — Section 5.15 —
> 
>   Rejected nominees, who consented to their nomination, and rejected
>   candidates must be notified prior to announcing the confirmed
>   candidates.
> 
> The comma before “who” shouldn’t be there.
> 
> — Section 6 —
> 
>   3.  The arbiter investigates the issue making every reasonable effort
>       to understand both sides of the issue.
> 
> This is better with a comma before “making”.
> 
> — Section 7 —
> 
>   It applies to IESG and IAB Members, the NomCom appointed IETF Trust
>   Trustees, and the NomCom appointed IETF LLC Directors.
> 
> “NomCom-appointed” should be hyphenated both times, and also twice in Section
> 7.1.
> 
> — 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
> 
> Then we let 7.2 et seq explain the common parts of the recall process,
> including appointment of the Recall Committee Chair.
> 
> — 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
> 
> — Section 7.7 —
> It would be worth adding, for absolute clarity, “The Recall Committee does not
> itself fill the open position.”
> 
> — Appendix C —
> 
>   4.  There are no term limits explicitly because the issue of
>       continuity versus turnover should be evaluated each year
>       according to the expectations of the IETF community, as it is
>       understood by each NomCom.
> 
> Make it, “There are no term limits for the IAB and IESG explicitly….”  There
> are now term limits for Directors and Trustees.
> 
> — Appendix D —
> 
> OLD
>   3.   The Chair contacts the IESG, IAB, and Internet Society Board of
>        Trustees and requests a liaison.
> NEW
>   3.   The Chair contacts the IESG, IAB, Internet Society Board of
>        Trustees, IETF Trust, and IETF LLC and requests a liaison from
>        each.
> END
> 
> 
> _______________________________________________
> iasa20 mailing list
> iasa20@ietf.org
> https://www.ietf.org/mailman/listinfo/iasa20