Subject: Genart last call review of draft-ietf-iasa2-rfc7437bis-05

From: Elwyn Davies via Datatracker <[email-masked]>
Date: Thu, 20 Jun 2019 00:53:50 -0700

Reviewer: Elwyn Davies
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-iasa2-rfc7437bis-05
Reviewer: Elwyn Davies
Review Date: 2019-06-20
IETF LC End Date: 2019-06-21
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with nits

Major Issues:

None

Minor Issues:

s3.2, para 1 and para 7: I feel the phrase 'superior candidate' is rather
demeaning to an incumbent who may have served with distinction. Suggest in para
1 s/a superior candidate/an alternative candidate/. In para 7 s/A superior
candidate  is one who the NomCom believes/The nominated candidate selected for
each open position by theNomCom, whether incumbent or alternative,  is the one
that they believe/

Nits and Editorials:

s2, Confirmed Candidate: s/that has been/who has been/ (for consistency with
Candidate)

s3.2, para 1: s/its incumbent/its incumbent, assuming that the incumbent has
indicated willingness to continue in post,/

s3.2, para 2: Section 5.4 of draft-ietf-iasa2-rfc4071bis-04 indicates that
there are term limits for the IETF LLC board positions and Section 2 of
draft-ietf-iasa2-trust-update-02 indicates there are term limits for IETF Trust
positions.

s3.3, para 3: s/is selected/are selected/

s3.7.1: The summaries of expertise need to be made public to facilitate
candidate's ability to address the requirements in their submissions to the
NomCom and for others to make appropriate comments on candidates.

---

From: John C Klensin <[email-masked]>
Date: Thu, 20 Jun 2019 07:59:20 -0400

Elwyn and other colleagues,

Four issues, noting in passing that the Last Call was on
draft-ietf-iasa2-rfc7437bis-05 and -07 was posted a week and a
half ago:

(1) To the extent to which the changes in this document are
supposed to be confined to those needed to reflect IASA -> IASA2
changes, fine-tuning language (such as "superior candidate" is
out of scope.  Given that changes proposed for other documents
from this WG have been rejected as out of scope because they are
not strictly part of the needed IASA2 changes, consistency is in
order.  Probably (and consistent with at least the spirit of
draft-roach-bis-documents even though I have other issues with
that I-D), perhaps this document (and most or all of the other
"bis-type" documents from this WG, whether in-progress or
awaiting publication) should be modified to include an explicit
note indicating their scope and that they omit coverage of
issues that might be, in the language of RFC 2026, "known
technical omissions" [1].

(2) Noting that the existing text does not say, e.g., "superior
person" or "superior human being", if we are going to change
"superior candidate" to something else to avoid being construed
as demeaning, "alternate candidate" (as proposed below) is not
the right fix.  From observation, there is already a strong bias
in the system in favor returning incumbents who are willing to
serve another term (whether that should be the case or not is
_really_ out of scope).  Telling incumbents that they were
replaced by an "an alternate candidate" could be construed as a
coin-toss -- without any substantive reason-- by the nomcom and
hence _really_ demeaning and implying criticisms that don't
exist.   So perhaps "superior choice for the position after the
nomcom weighted all considerations" is needed, but let's be a
little careful about changes in wording to be superficially more
polite.

(3) I hope it doesn't get buried in the review process,
especially given that it is certainly out of scope as discussed
above, but, IMO, the last comment, "The summaries of expertise
need to be made public...", is very important and becoming more
so.  Even if judged only from the increasing amount of
information nomcoms are requesting in questionnaires, the level
of personal knowledge nomcom members (individually or as a
group) can be expected to have of candidates is declining.  It
is important that there be a check on exaggerated claims of
expertise; if those statements are confidential, the nomcom may
not even be able to inquire of others in the community about
their veracity.   Making that information public (perhaps
allowing the candidate to identify some information as
confidential and have it elided from the public version or
perhaps deciding that any expertise information that cannot be
made public should not be considered by the nomcom) would be a
reasonable remedy.   In any event, now that this issue has been
raised and given that it affects the nomcom's ability to
operate, failure to address it is a known technical omission and
the document should not progress until either it is addresses or
the IESG makes a specific exception.

(4) In almost the same light, draft-moonesamy-recall-rev raises
important issues about the fairness of the initiation phase of
the recall process covered by this document.   It would be
appropriate to delay this document until the community makes a
decision about what, if anything, to do about that issue or to
include in it an explicit scope statement and disclaimer or an
IESG statement about known omissions.   Moving it ahead without
any of those things makes a statement that there is consensus in
the IETF that everything in the document is just fine and I
suggest, reinforced by Elwyn's review and Subramanian's draft,
that such consensus does not exist.

best,
    john

[1]  I know that this is a BCP and not a Proposed Standard, but,
if we are going to try to make that fine a distinction, then
using the BCP category for any IETF procedural document that
intends to specify a procedure going forward is an abuse of the
standards process.   Either that or we are willing to hold our
procedural documents to a much lower standard than our technical
specifications, in which case much of the time spent in the
IASA2 WG trying to sort of fine details has been wasted.

--On Thursday, June 20, 2019 00:53 -0700 Elwyn Davies via
Datatracker <[email-masked]> wrote:

> I am the assigned Gen-ART reviewer for this draft. The General
> Area Review Team (Gen-ART) reviews all IETF documents being
> processed by the IESG for the IETF Chair.  Please treat these
> comments just like any other last call comments.
> 
> s3.2, para 1 and para 7: I feel the phrase 'superior
> candidate' is rather demeaning to an incumbent who may have
> served with distinction. Suggest in para 1 s/a superior
> candidate/an alternative candidate/. In para 7 s/A superior
> candidate  is one who the NomCom believes/The nominated
> candidate selected for each open position by theNomCom,
> whether incumbent or alternative,  is the one that they
> believe/
> 
> Nits and Editorials:
> 
> s2, Confirmed Candidate: s/that has been/who has been/ (for
> consistency with Candidate)
> 
> s3.2, para 1: s/its incumbent/its incumbent, assuming that the
> incumbent has indicated willingness to continue in post,/
> 
> s3.2, para 2: Section 5.4 of draft-ietf-iasa2-rfc4071bis-04
> indicates that there are term limits for the IETF LLC board
> positions and Section 2 of draft-ietf-iasa2-trust-update-02
> indicates there are term limits for IETF Trust positions.
> 
> s3.7.1: The summaries of expertise need to be made public to
> facilitate candidate's ability to address the requirements in
> their submissions to the NomCom and for others to make
> appropriate comments on candidates.
> 
> 
> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20

---

From: Bob Hinden <[email-masked]>
Date: Thu, 20 Jun 2019 09:41:24 -0700

Elwyn,

Thanks for the review.  Note the current draft that is out for IETF last call is draft-ietf-iasa2-rfc7437bis-07.

Comments below.

Thanks,
Bob

> On Jun 20, 2019, at 12:53 AM, Elwyn Davies via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Elwyn Davies

This original text from RFC7437 and with my editors hat on, I don’t think we should be rewriting the base text.   I think that is out of scope for this bis.

Personal comment.  I would hope that a NomCom doesn’t change sitting people unless the new person was superior.  Would we want them to just change someone who is doing a good job without good reason?

> s2, Confirmed Candidate: s/that has been/who has been/ (for consistency with

ditto

> indicated willingness to continue in post,/

ditto, but I also don’t think this is necessary here.  It’s made clear in p5 in the same section.

> draft-ietf-iasa2-trust-update-02 indicates there are term limits for IETF Trust

rfc4071bis is now -11
trust-update is now -03

This was fixed in draft-ietf-iasa2-rfc7437bis-07.  The text in -07 is:

   Although there is no term limit for serving in any IESG, IAB, or IETF
   Trust position, the NomCom may use length of service as one of its
   criteria for evaluating an incumbent.

I don’t see any mention of term limits in draft-ietf-iasa2-trust-update -02 or -03.  Where did you see that?

> s3.3, para 3: s/is selected/are selected/

There are only two paragraphs in Section 3.3, I think you mean para 1.

> NomCom and for others to make appropriate comments on candidates.

I assume you are proposing to add this text.   While I personally agree, I think it’s out of scope.