I'm not sure this message belongs on this list in this last call,
but I'll admit that at this point I'm a bit flummoxed where to
reply such that a productive community discussion can take place
about the issue Adam raises.
[about why he's been in the organization a long time]
Me too, and somewhat longer.
Dan's behavior is an extreme example of a pathology that I've seen grow in the IETF over the past decade or so: while the magnitude of his actions is exceptional, the general direction they're taken in is sadly less so.
Alas, I did a bit of a review of ancient IETF archives just to try to understand the trajectory. This involved reading email via emacs, compiling Columbia MM written by Fuat Baran and others in the hopes that what I was looking at was mtxt (it wasn't; sigh).
What I discovered is that we have occasionally had these outbursts pretty much all along, including some (regrettably) from me. This has happened in some rather heated debates, particularly where people felt that the direction of the organization was at stake. To give you some idea how far back this goes, there was heat in the network management protocol wars back around 1987 involving SGMP, HEMS/HEMP, etc. There was heat in discussions around IGPs, and there was a LOT of heat in PPP discussions. In one instance, a participant shouted and screamed in person at another one for not having read the specifications. There was some heat in the early smtpext discussions. Oh those umlauts! There was a LOT of heat around CIDR because end user control of the address space was pitted against ISP and router COGS issues. There are other examples that predate Adam's arrival, and a good number that come later. Who can forget the war that took place in the RRG around 2008? And I believe there was one instance in which one participant challenged another person to a duel with swords.
I will note that in all of these instances, the group got on with
the work at hand, either in spite of or with the help of some
heat. Hard to tell.
Two things have changed, in my opinion:
- Many people's tolerance for that sort of behavior; and
- How we choose to resolve it.
I mostly do like that we are not so tolerant, but I don't like how we resolve these sorts of PR actions. The openness we like engenders humiliation of the individual involved. This began with sergeants-at-arms and seemingly has gotten (in my opinion) worse. In any other standards organization, the matter would be handled a lot more quietly.
I would much rather that we redid BCP 83 to reflect this, that the matter fall to the IETF chair to resolve, and that that person should have some freedom of action, so long as it proposed and reported to the IESG. This can result in better outcomes and can be effected more quickly. While there is a risk of abuse of power, that risk is mitigated by having a handful of people with different perspectives review the proposed action.
That lack of openness is actually a benefit. When matters are
dealt with quietly and decisively, they can happen faster. For
instance, when I was chairing a calendaring working group, there
was one participant who had a tendency to be disruptive. In
consultation with the AD, we agreed that I would moderate his
participation for some period of time, and reject posts I felt
were offensive, a copy of which would go to the AD when such a
decision was made. He was made aware of his right to appeal. Not
a single message needed to be moderated, and he contributed as a
productive member of the group.
Also, IMHO there are benefits to the community in not having these debates out in the open. We're here to develop technical standards and guidance, not to debate people's behavior. Also, these actions can happen with more alacrity.
So I would prefer to reopen BCP 83 along the above lines. I'd
propose a mailing list if others are interested.
Eliot
Attachment:
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
