FW: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
sah at 428cobrajet.net
Fri Jan 20 03:45:49 CET 2006
List members who are not on the IETF list will miss this. You may wish to
read and reply to Sam's questions. If you do reply, please send your reply
to ietf at ietf.org and/or iesg at ietf.org.
From: Sam Hartman [mailto:hartmans-ietf at mit.edu]
Sent: Thursday, January 19, 2006 8:04 PM
To: Scott Hollenbeck
Cc: ietf at ietf.org; iesg at ietf.org
Subject: Re: IETF Last Call under RFC 3683 concerning JFC (Jefsey) Morfin
I agree that Jefsey's participation in LTRU and the ietf-languages lists has
Even by his own admission Jefsey has been engaging in filibustering--a
practice that I think we would agree is disruptive. Take a look at his most
recent appeal to the IESG
(http://www.ietf.org/IESG/APPEALS/jefsey-morfin-appeal.txt ); quoting from
This is why I chose to give the necessary time to common sense to prevail,
in exposing their mistakes in a way they could forced to correct some of
them. The democratic method for that is work and filibustering.
Filibustering is not pleasant. But it permitted to obtain what users'
As such, I agree that we need to adopt a strategy that prevents Jefsey from
disrupting our processes excessively.
However a PR action is an incredibly huge hammer. If passed, it removes any
process barrier to shutting Jefsey out of any IETF process. While this PR
action is specifically targeted at the ietf-languages list it would give the
person running any IETF list the ability to unilaterally remove Jefsey from
Perhaps this is an appropriate measure to take when all of a person's
participation are destructive and they have nothing to offer.
That's not true for Jefsey. Jefsy has made significant positive
contributions to the IETF list. He has worked to describe the perceptions
that the IETF, IANA, ICAN, and related entities are creating a US-centric
Internet. He has described concerns of global users and how our protocols,
including IDN, may not meet user requirements. These concerns are real and
parts of them have been worked on by long-standing members of the community.
Take a look at RFC 4185 for an example of a concern that Jefsey shares that
members of this organization have spent time working on. I personally have
found Jefsey's formulations of these concerns enlightening; I think he has
significantly helped me understand how the IETF might be perceived and what
some user concerns with our protocol might be.
I've also found some of his security comments and some of his comments on
IETF process issues useful.
So, I think it would be inappropriate to apply this hammer in this case.
Instead, I propose that we find a tool appropriate for the
problem: a way of limiting Jefsey's ability to block progress in areas where
he is clearly blocking our work but not preventing him from participating in
I'd first ask why repeated 30-day suspensions are ineffective. Harald seems
to be getting fairly efficient at suspending Jefsey on ietf-languages. I
believe he's been suspended on LTRU before. Is Jefsey actually doing much
damage there with all these suspensions?
If so, why not give Harald and the LTRU chairs the ability to suspend Jefsey
for longer? That might involve a new BCP (or a process experiment), but if
we determine the existing tools are inadequate then that seems like a
reasonable option. How would a six month suspension be insufficient? Do we
really need an unlimited suspension to get work done?
Finally, if we somehow all convince ourselves that asking chairs to revisit
suspending Jefsey every six months is unacceptable then what about creating
way to suspend Jefsey from langtags related issues but not other IETF lists?
Sure, Jefsey is annoying on the ietf list, but is he really so much worse
than me ranting about fairness and openness, Keith ranting about
architecture or Dave Crocker ranting about timely standards development that
we cannot have a place for him? Speaking as an individual, if I had to pick
conversations to have un-had on the IETF list, there are ones higher on my
list than Jefsey.
Thanks for your consideration,
More information about the Ietf-languages