I see at least five different topics discussed in one single thread.
1. there are two different debates. The debate confuses my case and the need to better manage the IETF conflict resolution system. I have tried to differentiate what belongs to what and to help taking advantage from my experience for the general good. But I certainly follow my own pragmatic strategy. This mail is an attempt to help.
2. the qualification of the conflict. My case is typical: I am accused to have disrupted the consensus effort. I have actually obtained the consensus I was denied, with the appeal responses I wanted. The conflict was therefore not an RFC 3863 conflict. It was up to the Chairs, to the AD, and to the IESG to correctly requalify it. I thought Brian would do it. May be he had not the authority or the desire?
3. the particular nature of my own position. I always made clear I carried IETF deliverable user QA, not being a "co-designer" but an external system designer only wanting to help, obtain, or preserve interoperability with non IETF solutions like mine. As such, I obviously object to the RFC 3935 defined IETF mission "to influence the way people [me in this case] design, use and manage the Internet" and its resulting effort of exclusion and DoS of what is perceived as a technical "competition" of mine.
4. the different types of conflict. This is the most important point for the IETF common process. The IETF needs to address at least three different kinds of conflict for a single solution.
4.1. technical conflicts. These conflicts can result from a mistake, or from external interferences. The IESG's target should be to avoid the errors and to protect the IETF from external short terms or unilateral interests. The two main sources of these problems have been clearly identified as "affinity groups" (RFC 3774) and "commercial R&D funding" (IAB RFC 3869).
4.2. personal issues. The IETF is a human group where there can be ad hominem conflicts, attitudes, or deliberate actions. I disagree that they should be carried through external judicial process. For three reasons I experienced: (a) the IETF is not organized to take the outcome into account (b) a judicial process may involve the IETF if it is claimed it fostered the ad hominems (c) IETF participants have not been educated of the resulting risks. Instead the IETF should organize itself to mechanically prevent defamation. IMHO the error is the RFC 3863 public LC and the lack of balanced risk for the plaintiff in case of DoSing an opponent.
4.3. IANA registries. The IETF RFC 3935 "influence" is limited by the market adhesion to its standards. In the case of IANA registries there is no market alternative [we saw that in the alt-root case]. The control of a IANA registry can therefore be strategic. Until now the IANA had three main areas: numbers, names, protocol parameters. The numbers/names are pure Internet issues but were considered sensible enough to be delegated to ICANN. The new area of languages is not an Internet issue, is far more important and sensible than names and numbers, and is de facto [this is what I object] delegated to UNICODE. The IETF is obviously not prepared to this kind of fundamental conflict.
5. IETF strategy. There are cases where a possible solution is a significant change of the IETF, or even to kill the IETF itself. The conflict I am engaged into, is certainly of that nature. RFC 3935 gives "IETF leaders" the capacity to address such situations, except when the opposed option is defended by one/several IETF leaders. We should not consider that such conflicts are exceptional: the lack of architectural guidance by the IAB raises several other issues. After the Multilingual Internet, what about the multilateral, the multitechnology, etc. support?
Ad hominem rules. It is always advisable to take advantage from experience, but it is always unadvisable to build rules in considering one single case. And doing that to reduce the normal appeal mechanism which is part of the normal process. The only direct effect of my PR-defamaction was to permit my ban from a list I had left and from a list where I had sent my last mail. However, the indirect effect is to maintain a temporary situation [the RFC 3066 Bis had addressed] to prevent me to participate to the IANA Language Registries review process (and obtain interoperability with "my" system in sensible areas). This kind of ad hominem ruling absurdly perpetuates a contention point which hurts the IETF/IESG/IANA image and credibility, and I can so easily dispute or overcome.
jfc
At 16:41 22/07/2006, John C Klensin wrote:
Hi.
I had hoped to stay out of this one, but the volume has risen to
a level...
It seems to me that some major and important principles are
being lost in the noise, so let me suggest a different point of
view. The following is, obviously, just my opinion.
Appeals, in the IETF, are not a judicial procedure. They are a
mechanism for encouraging/ forcing another look, or a broader
look, at a decision. We have appeals to the IESG about IESG
actions precisely because the function of such an appeal is to
say "you may not have understood the issues correctly, please
take another look, considering these issues in particular" and
not "please judge this behavior".
While there is no requirement to do so, an appeal that asks the
IESG to review one of its decisions, or a decision or action by
one of its members that has not been resolved by discussion with
that member, should probably be made public by the person
initiating the appeal if there is any reason to believe that
community discussion will help inform the IESG review and
reconsideration.
At least IMO, the correct action if members of the community
believe that an IESG member is persistently misbehaving or
acting against community interest is not a series of appeals
from individual actions, but, depending on timing and urgency,
discussions with the relevant Nomcom or a recall procedure. If
those mechanisms are ineffectual, then we need to concentrate on
fixing them, not on trying to retune or recast the appeals
procedures to compensate for the problems with Nomcom or recall
procedures (see Note 1, below).
One major difficulty with the appeal procedure --or any
reconsideration procedure-- is that, if it is used outside the
model of cooperatively initiating a second look at a decision
and in the spirit of making the IETF produce better results
within its general framework, it can easily become an avenue for
DoS attacks on the IETF process. We have learned in recent
weeks that this is particularly problematic when the intent of
the IESG (or other) action was to block a denial of service
attack on the IETF or one of its WGs or other activities. If
that action can be appealed, and the decision to uphold the
action can be appealed, and the mechanisms used to make those
decisions can be appealed, we have what Ted described as a
"turtles all the way down" situation. In such a situation, the
appeals, and discussions of the appeals, can become a more
effective mechanism for denial of service (or just drowning the
IETF mailing list in noise) than the original (actual or
alleged) abuse.
It seems to me that, if an appeal involves an action connected
to a claimed denial of service attack on the IETF (with mailing
list abuse being the primary example) we need a procedural model
that bars the appellant from initiating (or even participating
in) a post-decision reprise on the IETF list, especially if
there is also an intention to initiate an appeal of that
decision. We've also got to figure out how to prevent multiple,
or layered, appeals resulting from the same action or decision
or appeals about it.
It also seems to me that we need to bar, or at least seriously
constrain, discussions that try to evaluate or complain about
appeal actions by assuming they are judicial processes and then
building arguments about the behavior of such processes. If
appellants really want a judicial process, let them go off an
try to find judges of competent authority they can convince:
none of our appeal (or review) mechanisms are ever going to be
appropriate under those models and attacking them because they
are not is, itself, either a denial of service attack or, at
least, a situation in which the noise far outweighs the signal.
While I personally believe that it shares some inappropriate
assumptions with the way RFC 2026 is sometimes read and that it
may not have the proper balance of protections for the
community, I commend draft-carpenter-ietf-disputes-00 as an
attempt to rethink this area. People who are interested in this
topic should probably study it.
john
Note 1: They may or may not be the right answers, but I've made
some proposals in this area. draft-klensin-recall-rev-00 (long
expired) was intended to make it easier for the IAB or IESG to
identify problems in their own environment that were linked to
individuals and initiate a community process to solve them. And
draft-klensin-chair-empowerment-01 is intended to permit the
IETF Chair to initiate specific, and faster-track, action if a
problem within the IESG gets out of hand.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf