Re: Appeals, post-appeal discussions, DoS attacks on the IETF, and the d

Dear John,
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 mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf