--On Sunday, March 31, 2019 16:44 -0400 Keith Moore
<moore@xxxxxxxxxxxxxxxxxxxx> wrote:
> On 3/31/19 4:14 PM, John C Klensin wrote:
>> I don't believe that it is useful to go down the path of
>> counting recalls but, if one looks at the statistics alone,
>> one could reasonably conclude that:
>...
> It's also possible that the mere existence of a recall
> procedure has served as an effective incentive to "behave"
Yes. No way to know, of course. On the other hand, I'm aware
of several cases in which threats to trigger the procedure were
made if behavioral changes did not occur. To be effective, both
the incentive you cite and such threats need to be credible.
One view of the argument behind draft-moonesamy-recall-rev (in
additional to the appearance of fairness) is that the needed
credibility is decreasing and that some small amount of tuning
would help restore it.
> (Note that one might still expose oneself to a recall attack,
> with the associated risk of hassles and threat to one's
> reputation, even while arguably doing the right thing. So
> "behave" might not be the right term here, but it will do for
> now).
Ack.
>> If one believes that latter, and that one can extrapolate from
>> 22 years of no recalls into the future, then we either don't
>> need the mechanism at all or we should got back to "anyone
>> can". On the other hand, should one believe that people might
>> end up on leadership bodies in the future (especially given
>> that we keep generating more of them) who might then behave
>> in ways that would justify recall actions _or_ if one
>> believes that the appearance of fairness toward all who
>> participate actively in the IETF is important, then changes
>> of the sort proposed in draft-moonesamy-recall-rev are worth
>> making and the number of past recalls is really not
>> particularly relevant.
>
> If I'm looking at how to defend a computer system or network,
> I don't care whether an attack has been exploited in the past,
> what I care about is how easy it is to make such an attack
> effective and how much damage it could do. Zero-day exploits
> are still exploits and in some sense are more of a risk than
> well-known exploits I don't immediately see why IETF should
> consider potential attacks on its operation any differently.
No disagreement there. But there are two possible kinds of
attacks on the IETF and its operation to be considered here.
One involves someone behaving in an outrageously bad way that
may, itself, be a threat to the IETF if allowed to continue.
The other is the one I think you are concerned about, e.g., the
recall procedure itself being used as an attack. The
combination suggests that we need a recall procedure (or some
complete replacement for it) that is credible and usable if ever
actually needed while striking the best balance possible with
the possibility of its being used as an attack vector.
>...
> I also prefer "fair" countermeasures against attacks on IETF -
> which I would define to mean countermeasures that don't
> discriminate in favor or against one kind of contributor over
> another, /while still allowing IETF to function effectively/.
And, again, the main argument for draft-moonesamy-recall-rev is
that the recall procedure is no longer fair and credible (if it
ever was or has been after the RFC 3777 changes) and that some
adjustments (IMO, fairly minor ones) are needed to restore both
fairness and credibility.
> Note that even though IETF derives much of its apparent
> legitimacy from the perception of fairness, an absolute notion
> of fairness must not be considered more important than
> effectiveness of the organization. IETF could be made
> "fair" by any of several silly means:
>
> 1. becoming so dysfunctional that it could never produce
> anything, thus
> giving every contributor an equal chance of producing
> nothing;
> 2. approving every draft (perhaps after a lengthy waiting
> period)
> without benefit of adequate review;
> 3. approving or disapproving drafts at random;
> 4. allowing anyone at all to veto any proposal
>
> all of which would defeat the very reason for IETF's
> existence. (These might seem like strawmen, but sometimes I
> think we're getting dangerously close to b.)
No disagreement from me.
> Keith (with some help from Harrison Bergeron)
>
> p.s. I very much appreciate the massive efforts that have been
> made, by very many parties, to make remote participation as
> effective as it is now. (The NOC teams get a special
> mention as do the Meetecho folks and also meeting sponsors,
> and I'm sure I'm leaving a lot of people out.)
Me too. But, in a way, we need to accept that the success of
those efforts, moving remote participation from something a
regular f2f participant might use occasionally to get by to an
effective way to actively participate while coming physically to
few or no meetings, require other adjustments. A lot of that
work has fallen on the tools team, especially Henrik, because
of, e.g., the need to adjust the way agendas are handled, and on
various educational efforts. The IETF does not, IMO, appreciate
those efforts often enough and clearly enough. The need to
look at IETF procedures that were originally developed in and
just after the POISED effort of the first half of the 1990s and
occasionally tuned since and address the question of whether
they are appropriate to 2019 reality is also on that list. From
that standpoint, this effort to tune the recall procedure is
just one such measure.
best,
john
