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

From: Barry Leiba via Datatracker <[email-masked]>
Date: Mon, 24 Jun 2019 16:09:51 -0700

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?

----------------------------------------------------------------------
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

---

From: John C Klensin <[email-masked]>
Date: Tue, 25 Jun 2019 01:21:17 -0400

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 <[email-masked]> 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.  

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 25 Jun 2019 08:32:43 +0100

> making a change that the WG was not allowed to make seems highly

I don't think what I'm suggesting is a change, but a clarification.
The intent of the current three-of-five policy is in-person
attendance, and there was no need to say that when that was the only
way to attend.  While I fully think that we should change that and
include remote participants for eligibility, this document is
addressing the current rules, which don't include them.

I strongly hope that we change that soon.  But I do think it's
important to get this document out there now, to finish the necessary
IASA2 documentation.

Barry

---

From: John C Klensin <[email-masked]>
Date: Wed, 26 Jun 2019 17:34:27 -0400

--On Tuesday, June 25, 2019 08:32 +0100 Barry Leiba
<[email-masked]> wrote:

>> 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.
> 
> I don't think what I'm suggesting is a change, but a
> clarification. The intent of the current three-of-five policy
> is in-person attendance, and there was no need to say that
> when that was the only way to attend.  While I fully think
> that we should change that and include remote participants for
> eligibility, this document is addressing the current rules,
> which don't include them.
> 
> important to get this document out there now, to finish the
> necessary IASA2 documentation.

No disagreement about that, and I think the document is ok to go
with the "IASA 2.0 only" text that I suggested included.
However, while things have clearly gotten better, easier, and
more effective, we've had remote participation (originally via
IP Multicast if you remember that) very nearly forever (at least
in Internet years).  Speaking personally, I participated
remotely in IETF 91 and 92, which span the time that 7347 was in
the publication queue.  So let's get the document out without
changes or clarifications that aren't strictly within the "fix
for IANA" scope with the understanding that, if it is a problem
now, it was a problem in early 2015 as well and does not need
extraordinary treatment.

   john

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 28 Jun 2019 10:24:29 -0400

Hi Barry,

> On Jun 24, 2019, at 7:09 PM, Barry Leiba via Datatracker <[email-masked]> wrote:
> 

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

> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20

---

From: Barry Leiba <[email-masked]>
Date: Fri, 28 Jun 2019 17:37:56 -0400

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

OK, that covers the second and third points, and I'll move them down
to comments so they're recorded for later.

But on the first point it's either sufficiently unclear that I don't
understand it, or it's broken.  I *would* like to discuss that and
make sure that if it's truly unclear (and not just fuzzy brain on my
part) or broken we fix it.  It would be a bad idea to publish an
update such as this with a rule that isn't usable (as opposed to one
that we think should be changed later).

Barry

---

From: Bob Hinden <[email-masked]>
Date: Fri, 28 Jun 2019 21:15:30 -0700

Barry,

Regarding you first point:

> On Jun 28, 2019, at 2:37 PM, Barry Leiba <[email-masked]> wrote:
> 

I think what these steps are saying that the steps need to be done in this order.  For example, even though the NomCom might think there will be an opening on the IAB because they just appointed a sitting IAB member to, for example, an IESG position, they can’t fill that open position until the person resigned from the IAB and after they have heard from the IAB Chair that there is a mid-term vacancy.  Then the NomCom can act to fill the vacancy.

Bob

---

From: Barry Leiba <[email-masked]>
Date: Sat, 29 Jun 2019 09:09:53 -0400

> I think what these steps are saying that the steps need to be done in this order.  For
> example, even though the NomCom might think there will be an opening on the IAB
> because they just appointed a sitting IAB member to, for example, an IESG position,
> they can’t fill that open position until the person resigned from the IAB and after they
> have heard from the IAB Chair that there is a mid-term vacancy.  Then the NomCom
> can act to fill the vacancy.

I get that.  And, so, in that case, how can "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", given that earlier in Section
3.8 it says this:

   The resignation should be effective as of when the term of the new
   position begins.  The resignation may remain confidential to the
   IESG, IAB, IETF Trust, IETF LLC Board, and NomCom until the confirmed
   candidate is announced for the new position.  The process, according
   to rules set out elsewhere in this document, of filling the seat
   vacated by the confirmed candidate may begin as soon as the vacancy
   is publicly announced.

That seems to say that the NomCom can't begin the selection process
for the replacement until the vacancy is publicly announced.  So I'm
trying to understand exactly what "exception" is being explained in
the text I originally quoted, and I don't see how the four-step
ordered process changes the effect of the text immediately above this.
That's what I'm trying to understand.

Barry

---

From: Bob Hinden <[email-masked]>
Date: Sun, 30 Jun 2019 10:13:16 -0700

Barry,

> On Jun 29, 2019, at 6:09 AM, Barry Leiba <[email-masked]> wrote:
> 

> That's what I'm trying to understand.

I am reading this differently, it says "The resignation may remain confidential”.  This allows the candidate to be confirmed but not announced.   I read the IAB exception to allow all of the steps to be taken and then make the announcement when it is all completed.

I note this text is original to RFC7437, so unless we have heard from a NomCom that this has causing a significant NomCom problem, I continue to think that we shouldn’t change it as part of the IASA 2.0 work.

Bob

---

From: John C Klensin <[email-masked]>
Date: Sun, 30 Jun 2019 15:14:04 -0400

--On Sunday, 30 June, 2019 10:13 -0700 Bob Hinden
<[email-masked]> wrote:

>...
> I note this text is original to RFC7437, so unless we have
> heard from a NomCom that this has causing a significant NomCom
> problem, I continue to think that we shouldn't change it as
> part of the IASA 2.0 work.

Given other clarifications and improvements that have been
deferred on the grounds that they are out of scope for the IASA2
WG, I would have said "so even if we have heard...".  

IMO, it would be entirely appropriate to file an erratum against
7437 -- the text is unquestionably hard to follow -- and then
transfer / transpose that erratum for 7437bis.  It seems to me
that one of the things some combination of document authors, the
WG co-chairs, any concerned ADs, and the RFC Editor staff should
do as soon as numbers are assigned to these IASA2 documents is
to be sure that all errata on original documents that have not
been processed and incorporated in the replacement ones are
immediately duplicated for the new ones.  And, as I have said
before, I sincerely hope that the publication of 7437bis (and
similar documents) will encourage, rather than delay, drafting
of replacements or updates to deal with those out of scope for
IASA2 issues.

Otherwise, I hope obviously, +1

best,
  john

---

From: Barry Leiba <[email-masked]>
Date: Sun, 30 Jun 2019 17:33:08 -0400

>
> I am reading this differently, it says "The resignation may remain confidential”.  This allows
> the candidate to be confirmed but not announced.   I read the IAB exception to allow all
> of the steps to be taken and then make the announcement when it is all completed.

One more pass on this before I give up, because I continue to think
that not correcting a true process error is a really bad choice, and I
don't see any other true process errors in the document.

> I note this text is original to RFC7437, so unless we have heard from a NomCom that this
> has causing a significant NomCom problem, I continue to think that we shouldn’t change
> it as part of the IASA 2.0 work.

The IESG doesn't generally just accept faulty documents on the grounds
that the fault wasn't caught the last time the document was updated,
so it's OK to leave the fault in this version.  I'm OK with the other
things, which are perhaps not as clear as they might be, but are not
actually wrong.  So I'm trying to sort out whether this is actually
*wrong*, or whether I simply am missing something.

So...
Maybe what I really don't understand is the exception that allows the
replacement process to be done before the vacancy is announced.  3.8
says, "The process [...] of filling the seat vacated by the confirmed
candidate may begin as soon as the vacancy is publicly announced."
The reason for that is to allow the community to put their names in
for consideration for the newly vacated position.

Is the exception trying to say that it's OK to fill a vacated IAB
position without soliciting new nominations, on the grounds that the
original call for IAB nominations should cover that, as the
nominations for the IAB are general enough?  In other words, it is
that we expect that anyone interested in an IAB position would have
already put their names in, and suddenly knowing that Joe Slobotnik's
IAB position is also open would not make a difference?

Barry

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 1 Jul 2019 11:10:01 +1200

Barry,

> replacement process to be done before the vacancy is announced. 

I don't believe that is the intention. I think the intention was to describe
exactly what happened in 2013:
https://mailarchive.ietf.org/arch/msg/ietf-announce/ogw1xIIrxXN-ExzUmordL1uXetk
https://mailarchive.ietf.org/arch/msg/ietf-announce/EwBi_PHbPs3a4CqJwYDjObb2VSc
i.e. an hour or so after an IAB member was announced as a new AD, NomCom
started the mid-term vacancy process. (I assume that in the intervening hour,
the IAB member resigned and the IAB duly informed NomCom of the vacancy.)

In other words "The process [...] of filling the seat" includes a call for
nominations, as it did in 2013. (The fact that it happened in May rather
than before the MArch IETF is beside the point, I think.)

I think that in this sentence:
"The resignation may remain confidential to the IAB,
 IAOC, IESG, and nominating committee until the confirmed candidate is
 announced for the new position."
the phrase "the new position" means (in the 2013 case) the Transport AD
position. Filling in the unknowns, the sentence reads:
"Spencer's resignation from the IAB may remain confidential to the IAB,
 IAOC, IESG, and nominating committee until Spencer is announced as
 the new Transport AD."

So yes, the wording could be improved to clarify what "the new position"
refers to. But (IMHO) that's an erratum, not a process bug.

Regards
   Brian

---

From: Barry Leiba <[email-masked]>
Date: Sun, 30 Jun 2019 20:20:03 -0400

Hi, Brian.

>  IAOC, IESG, and nominating committee until Spencer is announced as

Sure, but that's not what the text says:

   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

Putting the 2013 specifics into that:

   It is consistent with these rules for the announcements of a
   resignation of a Spencer from the IAB and **of the confirmed
   candidate to replace Spencer** to all occur at the same time

That second part is very different from the announcement of Spencer as
TSV AD (which I agree is no problem at all).  Having it as I've
inserted the 2013 specifics implies that Spencer's replacement on the
IAB was selected without letting community know that it was happening.

Barry