Replying at this point, but I've read past it in the thread, on one point. On Sun, Mar 31, 2019 at 6:15 PM John C Klensin <john-ietf@xxxxxxx> wrote: > > > > --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. I'm aware of more than one case like this, and since we don't discuss specifics, there's no way to know whether any of my cases are also John's cases, or anyone else's cases. But I can confirm that this has happened, and one assumes that the conversation had the desired effect because the threats didn't materialize in public as a submitted recall request. > 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. That's my view, and I appreciate that it's being discussed. I'm sure there are other views, because this is the IETF, of course :-) Spencer > > > (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 >
