IAB,
This is an appeal of the IESG's decision (announced 2023-08-24)
on my appeal of the "IESG Statement on Guidance on In-Person
and Online Interim Meetings" [1] (referred to as the "Guidance
Statement" below). I have delayed generating and posting this
appeal to you because I have wanted to see how some slightly
related issues might play out, possibly in ways that would make
the appeal far less necessary. However, we are coming up on the
two month limit specified in RFC 2026, so I believe I need to
go ahead now.
While I have not observed evidence of issues and abuses in
addition to those that stimulated the original appeal (and
which I deliberately did not identify in detail for fear of
creating distractions), the underlying issues with the Guidance
Statement remain. At least equally important, the IESG's
response to the appeal highlighted (I assume unintentionally) a
few more general issues that are described below and
that I urge the IAB to consider as it evaluates this appeal if
only to reduce or eliminate the likelihood of additional
appeals from members of the community who believe they have
seen other problems with the IETF's procedure development
and/or clarification processes.
Original Appeal Issues:
(1) Effectively closed interim meetings. As I understand the
IESG position as stated in the appeal response (exaggerating
slightly for emphasis and clarity), a meeting is not considered
closed unless people who know about it and want to attend are
somehow locked out. A f2f session during an IETF meeting would
be closed only if the door was locked and only people with the
secret password or key could get in, with active WG members
presumably given the password. My interpretation of our rules
and long-term principles and practices is that meetings are
required to be open to the community and that implies that
community participants, even those who are not active
participants in the and/or on its mailing list, need to be
notified of the meeting and arrangements for it, and notified
early enough that they can plan to attend.
As part of that appeal response, the IESG indicated that, in
some cases, WG chairs were "unaware that interim meetings are
scheduled through the datatracker so that the necessary
announcements are automatically sent". It was implicit in the
appeal that ADs should be monitoring their WGs, especially ones
with chairs who are new enough to not be thoroughly familiar
with how things work, to a sufficient degree to catch issues
like that and remedy them/ clarify things, before meetings
become, however unintentionally, exclusionary.
(2) Extended sequences of online meetings (sorry about the
confusion with hybrid meetings in the original appeal). The
problem I see, and to which I believe the appeal should have
elicited some correction, is best summarized by a paragraph of
the August 24 response that read:
"For extended sequences of *online* meetings, the IESG
statement requires the chairs to explain to the WG why they
believe them to be warranted, and to confirm consensus for
them. The responsible Area Director has ample opportunity
to review and discuss any concerns with the chairs and the
working group at that time."
The explanation is from the chairs to the WG, not to the AD.
There is no requirement to notify the AD that the discussion is
going on or what conclusion is reached. That would not be a
problem if there were a clear expectation that ADs would
closely track "their" WGs and discussions in them, presumably
following WG mailing lists and/or having frequent discussions
with WG Chairs about progress and decision-making within each
WG. However, the IESG has made it fairly clear that it is not
the expectation, most significantly responding to questions
about activities within some working groups by saying that they
trust the WG Chairs.
If the WG Chairs do not call the AD's attention to what is
going on, no other WG participants complain, and the AD is not
carefully following the WG's activity and progress (not just
reviewing documents recommended for IETF LC), then there are no
guarantees that AD will have any opportunity at all to
intercede in those decisions.
That is particularly important with WGs that are either small
(few active participants other than the chairs and editors),
very homogeneous in perspective (or possibly employers), or
both. At least from my point of view, part of the job of ADs in
those situations is to ensure that all WGs are, and remain,
open to the broader community and to different perspectives.
Having WGs whose members talk only with each other is not
necessarily a problem, but certainly poses a risk if there is
not significant external oversight. While one would hope WG
Chairs would pay careful consideration to those issues and
risks as well, they are not accountable to the broader
community and because groups all of whose members are in
complete agreement are inherently more efficient in producing
documents with which they agree than groups in which there is
more controversy, WG Chairs may actually have some incentives
to keep things closed.
(3) Large numbers of interim meetings, verification of
decisions on WG mailing lists, and interpretations of RFC 2418.
RFC 2418 does, as the IESG mentions, specifically discuss how
in-person meetings can help advance work. I have no problem
with that and the appeal did not suggest it. It does not,
however, discuss possible issues with large numbers of online
(or other) interim meetings other than to say "may also be
held". The first and last sentences of that paragraph are, I
believe, particularly important. The first requires that
"actions be taken in a public forum, and wide participation is
encouraged". Interim online WG meetings whose existence is not
generally advertised except to people who are already active in
that WG are not, in the IETF's traditional sense, a "public
forum" and do not encourage wide participation. The last
sentence says that "Interim meetings are subject to the same
rules for advance notification, reporting, open participation,
and process, which apply to other working group meetings". The
permissions the Guideline Statement gives the WG Chairs and WG
authorization to decide on interim online meetings and, in
particular, to schedule them in large blocks without
per-meeting notifications to the community (probably including
agendas or at least statements of topics to be discussed)
appears to me to violate the intent, and perhaps the letter, of
those portions of RFC 2418.
All three of those issues and the associated potential problems
would be very easy to remedy: WG Chairs could simply be
required to notify the responsible AD when online interim
meetings (like in-person ones already) are being planned and
supply the justification for them (as the current Guidelines
require be supplied to the WG) and get approval (or at least
the absence of disapproval). That would give the AD the
opportunity to intervene and force further discussions if there
appeared to be issues, guaranteeing that the "ample
opportunity" the IESG suggested is actually meaningful. At the
other extreme, an AD, once notified, could nod appreciatively
and move on to other things. I frankly do not understand why
the IESG is resistant to requiring such notifications unless
they feel that they would be a sign of distrust in WG Chairs.
Again, it is the ADs who are accountable to the community --
through plenaries, via the Nomcom, and, at least in principle,
the possibility of recalls. WG Chairs have none of those
accountability properties.
==========
Higher-level/ More General Issues:
(HL1) It appears from discussions on various IETF-related
mailing lists in the last several months that there are two
views of the relationship of WGs, including their work and
decision making, to the rest of the community. In one view, a
WG is free to function in whatever ways it (or specifically the
Chair(s)) find convenient and efficient in getting their work
done. If that includes pushing people out of discussions
because they disagree with WG leadership and/or consensus among
other WG participants, that may be justified because it is
likely to make WG work go more quickly and efficiently. From
that perspective, the only opportunity the portion of the
community who are not active participants in the WG get to
provide input -- including about possible conflicts with other
work the WG is unaware of or dismisses -- does not occur until
IETF Last Call unless an AD happens to notice. If the AD is
watching the WG only by assuming that, if there are issues, the
WG Chairs will bring them to their attention, noticing might be
a happy accident.
The other view, including my own since I started participating
in the IETF, is that the work of WGs should be as open and
transparent to the rest of the community --not just the
fraction of the community who are willing and able to invest
significant effort to track the WG's work-- as possible and
that WGs and their leadership are required to be open and
welcoming to interested parties (especially if they are
informed about the work) even when those parties have views
that are out of the WG mainstream. From that perspective, the
purpose of IETF Last Call is to function as an important final
check, not to be the only point at which people who have not
actively participated in the WG have an opportunity to review
and have input into its work.
(HL2) While the original appeal, and the discussion above, are
primarily about elements of the Guideline Statement that I
believe are potentially bad for the IETF and the Internet,
largely because they may reduce the wide participation and
inclusion of people with diverse perspectives that RFC 2418 and
other basic documents encourage or require, perhaps I am wrong
about that belief. The more fundamental issue is how far the
IESG is allowed, or even encouraged, to go in changing or
updating such documents by drafting a statement, asking for
community input, and then issuing a new statement with
interpretations of the orginals that some would think
consistent with the originals and the community input and
others would not. The IESG's apparent procedures for developing
and approving such statements are either part of the problem or
a symptom: When a document that is considered for publication
as an RFC is processed, we go through a formal IETF Last Call
(not a call for comments or a consultation) followed by an IESG
evaluation process. The latter requires each IESG member to
take a position on the document (or explicitly abstain from
doing so) and those positions are recorded. By contrast,
establishing procedures by processes similar to those used for
the Guideline Statement, require none of that. If,
theoretically, a member of the community was so disturbed (or
pleased) with aspects of such a Statement that they wanted to
raise the IESG decision about it with the Nomcom as part of
recommendations about candidates, they would have no way to do
so since the positions individual ADs took on the Statement (or
abstained from taking) are not public.
When we have documents, like RFC 2418, that are fundamental to
how the IETF works and that clearly represent (or represented
at the time) community consensus, reinterpreting them in
significant ways to adapt better to changing circumstances (or
for other reasons) should, at least IMO, require a draft
updating document, IETF Last Call, rough (at least) community
consensus, and recorded positions by individual ADs. Noting
that RFC 2418 has been updated by no less than five separate
RFCs, that is how we did things, at least until recently, since
it (and RFC 2026, with 15 updating documents) was published. If
that is no longer the expectation and the change can be made
without formal community agreement, we are moving away from
bottom-up decisions by rough consensus and dangerously close to
decisions by royal (or at least oligarchical) edict and a
decision-making process and set of procedures that may be
exclusionary of some IETF participants and unfair to others.
(HL3) Many of our procedures, including the standards-related
ones outlined in RFC 2026, are designed for the development,
processing, review, and approval of standards track documents.
They include the assumption that documents will be developed in
the community and require various type of review and the
associated checks to prevent or remedy unfair or unreasonable
practices (as well as technical errors) as those documents move
through the system. AFAIK, the community has never explicitly
specified a similar process for IETF procedures and related
documents or interpretations of them although we have tended to
adapt, and adhere closely to, the procedures developed for
standards-related documents. In this particular case and ones
like it, we have (or appear to have) an initial draft prepared
by the IESG; the IESG soliciting comments from the community;
the IESG evaluating those comments (if not in secret, in a way
that is not highly public) and revising the draft as it sees
fit; and then the IESG deciding to approve the draft. We should
consider whether the IETF and its procedures should work that
way, including whether old principles about the
inappropriateness of someone acting as judge and jury in their
own case, might apply.
=============
I believe the IAB should review the above, the original appeal
and the IESG's response, and, in whatever light they provide,
the Guidance Statement and then request that the IESG re-review
and modify the Statement and associated procedures. If nothing
else, the appeal implied and the discussion above spells out
ways to improve oversight of at least some types of WG
decision-making to lower the risk of blocks to openness,
inclusiveness, and fairness on one hand and WG and AD
accountabiliy on the other. More broadly and noting that the
last WG in the POISED series that established the basic rules
for the contemporary IETF concluded 22 years ago this month,
perhaps it is time for us to revisit fundamental questions,
questions far more fundamental than the more recent effort to
update documents to reflect the introduction and role of the
LLC.
Thanks for your consideration.
John Klensin
[1]
https://mailarchive.ietf.org/arch/msg/ietf/v5MAgNfCv4d8AGAyfzauWR_3t8l
