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 <noreply@xxxxxxxx> wrote:
> 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.
>
>
> _______________________________________________
> iasa20 mailing list
> iasa20@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/iasa20
