Re: IAB Response to Appeal from Jefsey Morfin

"JFC (Jefsey) Morfin" <> Wed, 01 February 2006 02:24 UTC

Received: from ([] by with esmtp (Exim 4.32) id 1F47ff-0000S3-Gt; Tue, 31 Jan 2006 21:24:35 -0500
Received: from ([] by with esmtp (Exim 4.32) id 1F47fc-0000Ql-13; Tue, 31 Jan 2006 21:24:33 -0500
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id VAA27360; Tue, 31 Jan 2006 21:22:45 -0500 (EST)
Received: from ([]) by with esmtp (Exim 4.43) id 1F47qX-0000rR-3N; Tue, 31 Jan 2006 21:35:49 -0500
Received: from ([] by with esmtpa (Exim 4.52) id 1F47ex-0002Du-3y; Tue, 31 Jan 2006 18:23:51 -0800
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Wed, 01 Feb 2006 03:23:25 +0100
From: "JFC (Jefsey) Morfin" <>
In-Reply-To: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"; x-avg-checked="avg-ok-3C527EA4"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d9238570526f12788af3d33c67f37625
Subject: Re: IAB Response to Appeal from Jefsey Morfin
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

I thank the IAB for the processing of my request. I acknowledge its decision.

The IAB has decided not to discuss the motives of the contention, but 
the use of RFC 3934 to legitimate a ban decision (also used in the 
three other cases). Harald Alvestrand indicated the reasons of this 
use: if the list "didn't behave as if it was subject to RFC 3934, the 
IETF would be justified in asking someone else to take on the job of 
running the list." This is consistent with the consequences he draws 
from the IAB decision: "the alternatives would be to declare that I'm 
making up the [list] rules on my own, or to declare that the list has 
no rules until the IESG decides; the last interpretation is not one 
I'm willing to run a list under."

This means that the IAB, Harald Alvestrand and I root the issue 
[which make us waste so much time for one year] in the unclear 
status, "basically, for *me* " (says Michael Everson, 
at 15:57 20/01/2006), of the RFC 3066 IANA mailing list. I hope this list will soon 
be a IANA managed mailing list, or that the IESG requires the WG-ltru 
to gives it a more precise status through RFC 3066 bis (a debate I 
proposed and I was denied).

I make a note of the IESG and of the IAB "no comment" concerning my 
propositions in the Multilingual Internet, users requirements and 
ethic areas. I now feel free to proceed along these propositions in 
the respect of the Internet standard process.

I received several "well done" mails. I consider that Harald and I 
are both only trying to do our best to clarify a complex issue to the 
benefit of the users and of the IETF. I genuinely hope the IAB 
decision will help us to openly discuss it, taking the necessary time.


At 19:28 31/01/2006, Leslie Daigle wrote:

>On 4 January 2006, the IAB received an appeal from Jefsey Morfin
>appealing the IESG decision to uphold the suspension of his
>posting rights to the ietf-languages list. According to the
>procedures in Section 6.5.2 of RFC 2026, the IAB has reviewed the
>situation and issues the following response.
>1. The Appeal Question
>The IAB interpreted this appeal to be as follows:
>The appeal concerns whether the IESG, in upholding the suspension of Mr.
>Morfin's posting privileges to the ietf-languages mailing list, made an
>incorrect decision.
>2. The Scope and Basis of the Appeal
>While Mr. Morfin noted several motivations for his appeal and
>requests that several questions be answered in response to his
>appeal, the IAB did not consider Mr. Morfin's discussion of
>internationalization issues. Rather, the IAB reviewed the appeal
>as it applies to the administration of IETF mailing lists and
>specifically to the removal of posting rights. In particular, the
>conclusions described here narrowly apply to the process used by
>the IESG in upholding the 20 Nov 2005 suspension of Mr. Morfin's
>posting rights on the ietf-languages mailing list. Finally, in
>considering the appeal, we observe that the IESG noted that no
>existing explicit mailing list policy RFC was applicable in this
>3. The Process used by the IAB to Review the Situation
>The question raised by the appeal is whether the IESG followed
>the Internet Standards Process in the upholding of the suspension
>of Mr. Morfin's posting rights to the ietf-languages mailing
>The procedure used by the IAB in considering this appeal has
>o Review of the documentation of the IETF's standards procedures
>     as described in RFC 2026 and RFC 2418,
>o Review of IETF Mailing List Administrative Procedures, as
>     documented in RFCs 2418, 3005, 3683, and 3934, and
>o Review of the context and history of this appeal
>4. IAB Considerations
>In its response to Mr. Morfin's initial appeal, the IESG notes:
>"RFC 3934 does not strictly speaking, apply to non-WG lists but
>we have considered it by analogy". The IAB found that RFC 3934 is
>specific to working group mailing lists: Not only is RFC 3934
>specifically identified as an update to RFC 2418 (which regards
>working group procedures), but the clearly stated purpose of RFC
>3934 is to give working group chairs similar authority on a
>mailing list as they have in face-to-face meetings. In
>particular, a working group chair can "refuse to grant the floor
>to any individual who is unprepared or otherwise covering
>inappropriate material, or who, in the opinion of the chair, is
>disrupting the WG process" during a meeting. It is precisely
>because of their designation as working group chair that RFC 3934
>provides the chair the ability to suspend posting rights without
>IESG approval. This calls into question the suspension of mailing
>list posting rights under RFC 3934 other than by working group
>chairs on working group mailing lists.
>The IAB also reviewed other IETF mailing list management RFCs.
>RFC 3683 refers to the "temporary suspension of posting rights to
>a specific mailing list." However, we were hard-pressed to find
>language in RFC 3683 that could have been applied in either the
>initial suspension or the IESG response. In particular, RFC 3683
>notes that those temporary suspensions are documented in RFC 2418
>(which, like RFC 3934, applies to working group chairs) and RFC
>3005 (where the IETF chair, the executive director, and a duly
>appointed sergeant-at-arms are the ones empowered to refuse
>postings to the mailing list), neither of which
>covers the case at hand.  As a result, we find there is no
>specific mailing list management process RFC that applies.
>While we find that neither RFC 3683 nor RFC 3934 directly apply
>in this case, the IAB understands that the IETF must be able to
>act in the face of ambiguity in "the rules." Indeed, it would be
>a terrible outcome if we found the IESG's decision would have
>been reasonable if neither RFC 3683 nor RFC 3934 existed, but now
>unreasonable since the documents do exist but don't
>apply. Moreover, current well-established practice allows for
>mailing list maintainers of any IETF mailing list, without
>prior approval, to remove or block posts from viruses or other
>operationally-disrupting e-mail sources, and we are not offering
>a decision that we believe contradicts that. Responsible parties
>must be able to take action even if there is ambiguity or lack of
>explicit coverage by specific process documents.
>Of course, these actions are not arbitrary: RFC 3934 limits working
>group chairs to only restrict posting rights in order to support
>constructive work on the working group's chartered activity, and
>current list maintainer practice is only to block postings from
>operationally-disruptive sources. In the spirit of RFC 2026 and
>RFC 3935, those actions must be governed by appropriate judgment
>and the basis for such judgments should be clear and public.  The
>IAB believes this is imperative in order to ensure that the IETF
>continues to function in the most open and fair manner possible,
>for all participants.
>5. IAB Conclusion on the Appeal
>The IAB found that the response provided by the IESG in this
>action did not provide sufficient justification to sustain the
>banning of Mr. Morfin from the ietf-languages mailing list. In
>particular, while the IAB agrees with the IESG that no specific
>mailing list process RFCs directly apply in this case, its
>response is not sufficiently clear why RFC 3934 is considered
>applicable "by analogy". Further, it is also unclear from the
>IESG's response what the scope of applicability of RFC 3934 might
>be, or when other process RFCs  might be applied "by
>analogy". Therefore, the IESG's action does not meet the clear
>and public requirement outlined above and the IAB annuls the
>IESG's decision in this appeal and sends the matter back to the
>IESG for resolution.
>Since the suspension period has expired, no remedy is
>indicated. However, the IAB recommends that the ambiguities that
>gave rise to this appeal be clarified, as described in the
>following sections.
>6. IAB Recommendations
>6.1 Clearly Define the Operation of IETF Mailing Lists
>If mailing list participation rules are to be based on
>contributing constructively to work items, the IETF should
>consider making public charters for those lists (however formal
>or informal) so that people understand the scope of the work, the
>person responsible for shepherding the discussion in accordance
>with the charter, and rules governing participation in those
>lists. In particular, future RFCs (or revisions of existing RFCs)
>governing mailing list administration should clearly indicate who
>the responsible parties are as well as the extent of their
>6.2 Disambiguate Current Mailing List Administration Procedures
>The IAB recommends to the IETF that the ambiguity in the current
>procedures be cleared up. In particular: RFCs 3005 and 3934 allow
>for posting rights revocation for specific mailing lists (the
>IETF main list and working group mailing lists) at the discretion
>of people directly responsible to and appointed by the IESG;
>RFC 3683 allows for posting rights revocation by any IETF mailing
>list maintainer, but only on the basis of an IETF-wide  consensus
>call (a high hurdle); current practice allows for posting rights
>revocation by mailing list maintainers in the case of operational
>emergencies; the large gap in between those procedures is not
>addressed, either by BCP or by well-established practice.
>6.3 Clearly and Publicly Document IESG Decisions on Appeals
>When deciding similar cases in the future, the IAB recommends
>that the IESG give clear and public support for the basis of
>their decision, either by providing clear documentation of the
>interpretation of applicability of existing process or by
>referencing well-established current practice.
>Leslie Daigle,
>IAB Chair.
>Ietf mailing list

Ietf mailing list