IETF Last Call Review of draft-ietf-modpod-group-processes-13
review-ietf-modpod-group-processes-13-tsvart-lc-scharf-2025-11-19-00

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.

This is a process document, and therefore the technical TSV-ART review criteria
do not apply. I comment on this document mainly from my personal point of view
as past TCPM working group chair.

Disclaimer: As far as I recall, in 11 years we had never such issues in the
TCPM working group. Therefore I am also not really familiar with the existing
IETF processes in this space.

The document clearly explains why a process change is needed, given the
existing gaps e.g. for repositories. Yet, as somebody who hasn't followed the
discussion resulting in this I-D, I struggle with understanding the motivation
for several aspects:

1/ Personally, I am not really comfortable with obsoleting several BCPs without
describing what the new practice should be. I would have expected that this
document specifies at least some baseline for the actual moderation guidelines,
and that the document gets IETF consensus on that. If it is difficult to get
(rough) IETF consensus on basics (this is what I understand from the text),
then it is not obvious why offloading the task to some few individuals will
result in a better solution.

2/ Maybe I have missed it, but I have not understood from the I-D where the
still-to-be-defined moderating principles will be documented. If e.g. WG chairs
run into this BCP after publication, it would probably help to know where to
search for the actual relevant Information. When I was a chair, BCPs were my
main source of information for non-trivial IETF process questions.

3/ Maybe this is off-topic, but it is not really clear to me if the planned
moderator team would also get involved if disruptive comments are written in
I-Ds. For instance, the abstract or content of I-Ds may automatically be posted
to public IETF fora. What is the role of moderators in that case? Is this topic
entirely out-of-scope of this BCP? Maybe disruptive I-D text is also already
completely covered by other BCPs or policies. If so, it may help to provide a
pointer to those other guidelines, for persons (like me) who do not know all
process BCPs out of their head.

4/ Unlike for IETF-wide fora, the need for moderators inside working groups is
less obvious to me. I wonder what the vague sentence "moderators may take
actions when administrators do not respond to reports in a timely fashion"
actually implies, specifically the term "timely". When I was TCPM chair, I have
typically reacted to posts on the WG mailing list within two business days.
When reading this I-D with comments about different timezones, it is not clear
to me if this order of magnitude of reaction time falls is still "timely", or
not. If the IETF indeed needs a new process and a new rule, it should be
possible to explain why chairs are not good enough, or what is expected from
chairs to avoid actions from moderators in their working group.

According to the shepherd write-up, there has been controversy in some of these
areas, e.g., whether moderators only provide advice inside working groups.
Regarding the controversial topics, some additional reasoning in the document
would probably have helped me to better understand why the I-D text is indeed
the best solution for the IETF.

Michael