[Tsv-art] Tsvart last call review of draft-ietf-elegy-rfc8989bis-03

Bernard Aboba via Datatracker <noreply@ietf.org> Tue, 17 January 2023 00:10 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tsv-art@ietf.org
Delivered-To: tsv-art@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BBDC1522A0; Mon, 16 Jan 2023 16:10:52 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Bernard Aboba via Datatracker <noreply@ietf.org>
To: tsv-art@ietf.org
Cc: draft-ietf-elegy-rfc8989bis.all@ietf.org, eligibility-discuss@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.5.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <167391425199.31665.1635820288408751638@ietfa.amsl.com>
Reply-To: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 16 Jan 2023 16:10:52 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/nl-CdWgHqdQ1pVinxZn4qbZKeFs>
Subject: [Tsv-art] Tsvart last call review of draft-ietf-elegy-rfc8989bis-03
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jan 2023 00:10:52 -0000

Reviewer: Bernard Aboba
Review result: On the Right Track

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

draft-ietf-elgy-rfc8989bis relates to Documents Nominating Committee
Eligibility, so strictly speaking, there are no Transport Area considerations
to review.

However, as a former NomCom Chair, I'll provide my thoughts on it.

Overall, I feel that this document is not crystal clear about exactly what
Sections of RFC 8713 are being updated.

The Introduction states:

"   This document replaces the attendance criteria in the first two paragraphs
of Section 4.14 of [RFC8713]... The other paragraphs of Section 4.14 of
[RFC8713] remain intact."

[BA] Instead of "The other paragraphs..." I would suggest substituting "All
other text in [RFC8713], including the other paragraphs of Section 4.14, remain
unchanged."

The first two paragraphs of Section 4.14 are:

"Members of the IETF community must have attended at least three of the last
five IETF meetings in order to volunteer.

The five meetings are the five most recent meetings that ended prior to the
date on which the solicitation for NomCom volunteers was submitted for
distribution to the IETF community."

I was therefore expecting the document to provide specific text that would
substitute for these two paragraphs.  In IETF documents, this is typically done
by quoting the OLD text, and specifying precisely what is to be substituted in
NEW text. For an example, see RFC 7983 Section 7.

Here is the text in Section 4:

"  The following paths to qualification replace the first two paragraphs
   of Section 4.14 of [RFC8713].  Any one of the paths is sufficient,
   unless the person is otherwise disqualified under Section 4.15 of
   [RFC8713].

   Path 1: The person has registered for and attended three out of the
   last five IETF meetings, either in-person or online.  In-person
   attendance is as determined by the record keeping of the Secretariat.
   Online attendance is based on being a registered person who logged in
   for at least one session of an IETF meeting.

   Path 2: The person has been a Working Group Chair or Secretary within
   the three years prior to the day the call for NomCom volunteers is
   sent to the community.

   Path 3: The person has been a listed author or editor on the front
   page of at least two IETF Stream RFCs within the last five years
   prior to the day the call for NomCom volunteers is sent to the
   community.  An Internet-Draft that has been approved by the IESG and
   is in the RFC Editor queue counts the same as a published RFC, with
   the relevant date being the date the draft was added to the RFC
   Editor queue.  For avoidance of doubt, the five-year timer extends
   back to the date five years before the date when the call for NomCom
   volunteers is sent to the community."

On reading this, I am not sure exactly what text is to be spliced into RFC
8713, and where the splicing begins.  Is the splicing supposed to begin with
"Part 1"?  If so, this is awkward because there is no introductory sentence
providing context. Also, I am not sure why RFC 8713 Section 4.15 needs to be
mentioned if this Section remains unmodified, but the document doesn't state
that unequivocally.

There is a bigger problem though, which is that the document does not fully
address the impact on nomcom operation.

Section 3 states:

"Finally, the NomCom interview process was largely conducted in-person at IETF
meetings, so the ability to attend was a prerequisite to participate."

[BA] While nomcoms have also made use of remote interviews, the ability to
connect with much of the IETF leadership in person during the initial IETF week
after nomcom appointment has been very helpful for orienting the nomcom
participants.  While it is not impossible for a remote nomcom participant to
join all the initial interviews,  where that initial IETF meeting was held in
an inconvenient timezone, the participant might need to spend much of the week
participating in interviews at an inconvenient hour.  This is a more onerous
requirement than attending a single session during an IETF week, or even
attending a few sessions during an IETF week.

Section 3 continues:

"While this document does not formally impose a requirement for the NomCom to
function entirely remotely, including remote-only attendees in the pool is
likely to effectively require a remote component to NomCom operations."

[BA] The idea of including remote-only attendees in the pool without thinking
through how the NomCom can function entirely remotely strikes me as a
significant omission.  I realize that this document can't specify exactly what
arrangements should be made, but I do feel that the requirements for
participation in the nomcom need to be clear, and that these might be different
than the requirements for joining the pool.  For example, if there is an
expectation that the nomcom chair will provide remote access to interview
sessions, that should be stated in the document.  Or if there is no
expectation, then perhaps the nomcom chair should include in the Call for
Participation information about remote participation in the nomcom.  It doesn't
strike me as useful for remote-only attendees in the pool to discover that they
cannot usefully participate in the initial IETF week interviews without any
prior indication that this might be the case.