Re: Fully functional email address
John C Klensin <john-ietf@jck.com> Fri, 20 June 2025 23:10 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@mail2.ietf.org
Delivered-To: ietf@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id F25CE3796C4E for <ietf@mail2.ietf.org>; Fri, 20 Jun 2025 16:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxlXmPPuTjX3 for <ietf@mail2.ietf.org>; Fri, 20 Jun 2025 16:10:43 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by mail2.ietf.org (Postfix) with ESMTP id 53C903796C46 for <ietf@ietf.org>; Fri, 20 Jun 2025 16:10:43 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1uSksT-000O5E-DL; Fri, 20 Jun 2025 19:10:33 -0400
Date: Fri, 20 Jun 2025 19:10:27 -0400
From: John C Klensin <john-ietf@jck.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Paul Wouters <paul@nohats.ca>
Subject: Re: Fully functional email address
Message-ID: <0D88458E71F31829A3FAF8FD@PSB>
In-Reply-To: <c9a2c2e6-4075-4520-b5b6-8c917abb6006@cs.tcd.ie>
References: <8cc02d64-9c6e-48aa-94bc-3dab4ed00f6c@cs.tcd.ie> <93C31BF9-61D6-452B-81B7-552D947EAC9D@nohats.ca> <c9a2c2e6-4075-4520-b5b6-8c917abb6006@cs.tcd.ie>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Message-ID-Hash: SY4V3ZJ55S6LOO5ZUQLVGGJ3XAXWCAE6
X-Message-ID-Hash: SY4V3ZJ55S6LOO5ZUQLVGGJ3XAXWCAE6
X-MailFrom: john-ietf@jck.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ietf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: IETF general list <ietf@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/0tClmkLVpNzgWo_B63Uvk96ZbEo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Owner: <mailto:ietf-owner@ietf.org>
List-Post: <mailto:ietf@ietf.org>
List-Subscribe: <mailto:ietf-join@ietf.org>
List-Unsubscribe: <mailto:ietf-leave@ietf.org>
Hi.
Without commenting at all about the appeals that seem to have
motivated this discussion (I actually have not taken the time to be
sure about what, or whom, is being referred to), a few comments about
part of the thread...
--On Friday, June 20, 2025 11:20 +0100 Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>...
>> "The IESG further wishes to highlight that the primary aim of the
>> appeals mechanism set out there is to resolve conflicts and move
>> the IETF as a whole towards consensus, and it urges all
>> participants to approach them in that light"
See below about this.
>> Seeing the amount of effort spent by the Responsible ADs, the IESG
>> and the IAB, I think we can ask such a person to avoid any
>> ambiguity about Note Well by sending one more email to the
>> Responsible AD, and that furthermore the community had already
>> been immensely accommodating and we have seen little to no good
>> will in return.
>
> Without commenting on the recent appeals, yes, an appeal from
> someone with a quirky mail setup makes things harder for those
> dealing with the appeal. It's still my opinion that those who
> are deciding appeals ought to go out of their way to make it
> easier for the appellant, even if they behave oddly with email.
Or behave oddly in other ways.
> ISTM the point of appeals is to improve the probability that we
> end up doing the right thing, and the more we impose formalities
> on appellants, the more that goal is harmed, even if in a few
> cases the "formality" is a more typical email setup.
This is what motivated me to write. I think Stephen is right and, to
some degree at least, the IESG statement (including the part quoted
above) may be a symptom of a problem or two. I've often wondered if
the use of the term "appeal" might be part of that problem. The
most useful "appeals" are those focused on things that might have
been missed, or inadequately considered as possibly important, in the
original decision. As soon as things are couched as "conflict
resolution" (above and in the first sentence of the Statement), we
start losing the very useful assumption that we are all working
together to get the right results -- "end up doing the right thing"
in Stephen's terms -- and see them as an attack on an AD or the IESG.
That leads to self-congratulatory statements if there are no appeals
in a given period and other ways to discourage the types of appeals
that would be the most useful.
With a different community -- especially IESG, but more generally--
view of appeals, it becomes more reasonable and obvious to treat
quirky email setups, quirky people, and quirky submissions as simple
cases of the nature of the mechanisms used in submitting the appeal
as getting in the way of the IESG efficiently understanding the
perspective and request. It then should be practical to move forward
with a model of the IESG working with the appellant to be sure the
issues and resulting differences of opinion are understood and then
consider them in that light rather than sitting in judgment to
resolve a conflict. And, from the appellant's side, to assume (or at
least pretend to assume) good faith on the part of the
decision-maker. E.g., that there was a misunderstanding or lack of
sufficient information rather than, e.g., malice or bias.
That does not require more rules or detailed procedures about, e.g.,
appropriateness of mail systems or how much accommodation is
appropriate. It just requires a change of attitude to, at least IMO,
something much closer than what was intended when RFC 2026 was
written and what we tried to do in the years thereafter.
Now, obviously, there are cases where that won't work, especially
cases that really are intended as attacks and/or attempts to block
progress as an end in itself. But a sincere effort to clarify, to
understand perspectives that may not have adequately figured into the
original decision or that, e.g., might have been excluded by an
excessively homogeneous WG that was not interested in other opinions
or perspectives, would, I think, make those cases obvious to the
community and the IESG and justify disposing of them without large
amounts of wasted time (and lay the foundation for the IAB and, if
necessary, the ISOC BoT rapidly dismissing them as well).
Let's try to get past conflict resolution and consider "appeals" as
an important safeguard and normal part of a process in which every
participant (and even responsible ADs) may not have time, sufficient
background, or be able to fully understand and participate in every
discussion and decision. If we can make this more about
cooperatively improving the odds that decisions will derive from
including all important information and will be made with careful and
fair consideration of all perspectives, then we will dramatically
increase the likelihood that we will end up doing the right thing.
It would also be healthy, IMO, if cases in which the IESG concluded,
with more information and perspective obtained during the appeal,
that the appellant was correct, to have that trigger some serious
examination about where and why the original decision went wrong and
how that could have been avoided. Not useful in every case and more
rules and procedures would almost certainly not be helpful. But, if
we discover that mistakes have been made. especially by omission of
perspectives or failure to capture information, let's try to learn
from them.
> Note: I'm not commenting above on the aspect of the recent appeals,
> where people seemed to be disagreeing about whether the appeal text
> was <this pdf> or <that html>, or was the same or modified, which
> is a different issue (though also ISTM involving irony and quite
> quirky behaviour;-)
I'm not either, but I agree with that observation. And, again, I
think the cure is not rules, restrictions, or obstacles but --as
courteously and professionally as can be managed -- explaining the
ambiguity or uncertainty and asking the appellant to clarify rather
than somehow treating the appeal text as formal text whose meaning
the IESG is responsible to discern. As long as we don't make
responding hard, an applicant's failure to respond to such a
clarification request in a timely and clear fashion should be grounds
for suspending processing on the request and, eventually, dismissing
it. Again, let's move away from analogies to judicial procedures and
focus on understanding, clarity, and making sure that all issues and
perspectives are fairly, openly, and transparently considered.
john
- Re: Fully functional email address John C Klensin
- Re: Fully functional email address John C Klensin
- Re: Fully functional email address George Michaelson
- Fully functional email address S Moonesamy
- Re: Fully functional email address Paul Wouters
- Re: Fully functional email address S Moonesamy
- Re: Fully functional email address John Levine
- Re: Fully functional email address Michael Richardson
- Re: Fully functional email address Christian Huitema
- Re: Fully functional email address George Michaelson
- Re: Fully functional email address John C Klensin
- Re: Fully functional email address S Moonesamy
- Re: Fully functional email address John R. Levine
- Re: Fully functional email address Salz, Rich
- Re: Fully functional email address Rob Sayre
- Email usage (Was: Fully functional email address) Jay Daley
- Re: Fully functional email address Stephen Farrell
- Re: Fully functional email address Jay Daley
- Re: Fully functional email address S Moonesamy
- Re: Fully functional email address Martin J. Dürst
- Re: Fully functional email address Christian Huitema
- Re: Fully functional email address S Moonesamy
- Re: Fully functional email address Stephen Farrell
- Re: Fully functional email address John Levine
- Re: Fully functional email address Rich Kulawiec
- Re: Fully functional email address Phillip Hallam-Baker
- Re: Fully functional email address Paul Wouters
- Re: Fully functional email address John C Klensin
- Re: Fully functional email address S Moonesamy