Comments in line...
On 05/11/2013 05:18, John C Klensin wrote:
--On Monday, 04 November, 2013 07:40 -0800 "Murray S. Kucherawy"
<superuser(_at_)gmail(_dot_)com> wrote:
...
I have a related question: Is the IESG the right body to be
making these sorts of declarations in the first place? It
seems to me that an engineering steering group is a bit
outside of its jurisdiction to be establishing what amount to
human resources positions. The analogy to the corporate
environment, i.e., technical managers and team leads, would
certainly be the wrong body to be taking on the creation of a
higher-level HR function.
Shouldn't this be coming from one of the operational bodies
higher up?
My first reaction to this question was: there is no "higher up"
except the IETF as a whole. So the question is really whether our
steering group chose to steer in a direction that the IETF as
a whole accepts (at the level of rough consensus).
In a way, your question is another symptom of the problem. A
volunteer organization for which it is important that people
_not_ have to apply for membership and for whom applying
sanctions against a participant is one of the most problematic
actions we can take has no business having a "higher-level HR
function".
As to the body, there are basically two choices:
(1) ISOC could do it for/to us, but we've probably be _really_
unhappy about that.
Certainly I would (and I've been a member of ISOC since 1992).
(2) The IESG, IAB, or IAOC could decide some action was
necessary and move toward taking it. I think we could quibble
for a rather long time about which of those bodies was most (or
least) appropriate to do it or create another group to do so.
While my personal guess is that the IESG is least obnoxious for
this sort of situation, I think the key issue isn't the body but
how it proceeds. For that purpose, it seems critical to me
(and, if I've correctly understood him, to Dave) that there be
real, explicit, community buy-in on any results and meaningful
IESG (or other body) accountability to the community for the
results.
What follows that is where I suspect I may differ from Dave a
bit. I'm prepared to have the IESG say "We have concluded that
doing something to reduce the harassment level and potential
around the IETF is important and no one has really disputed that
conclusion in on-list discussions. It is clear that there is no
consensus about exactly what to do and it doesn't seem likely
that one will emerge. Sometimes, it just isn't acceptable to
have lack of consensus (even rough) block doing anything at all,
so we are going to make the following moves... Here are the
names of those on the IESG who supported that move; if you don't
like it, or if we take actions like this too often for the
community's taste, fire us.". Now, I'd be a lot happier if the
hypothetical action included a policy that was clearly
experimental with an evaluation plan for going back to the
community after a year or so (thanks to Brian Carpenter for at
least part of that idea).
Well yes, I think a one-year trial run would be a wise approach,
but I should say that although a bit more to and fro with the
community would have been better, I also understand Jari's desire
to get something in place before this week. So I'm not as critical
as Dave and John. Nevertheless, it does seem to me that the IESG
doen't have *authority* in this area, even though they clearly
feel a responsibility. So there's no way out of dialogue.
BTW personally I didn't comment on the draft policy because it
seemed good enough and not worth twiddling the details. It's the
execution that matters, and that depends on the ombudshuman much more
than on anything written.
Brian
I'd be happier yet if that
evaluation plan included some meaningful measurements (but the
design, execution, and analysis of such measurements is part of
my real professional field, so I know better than most how hard
that is and what the traps are in trying it). In a sufficiently
unusual situation, the presence of some data and experience, if
the community can't reach (even rough) consensus on what to do,
running code may trump consensus.
But, generally, I think we should all be concerned when the IESG
starts making proclamations about important IETF participation
issues, especially if those proclamations could lead to
sanctions that could be very troublesome indeed. If the IESG
concludes that they need to take a significant action that is
not the result of clear community discussion, support, and rough
consensus, then I expect them to follow the spirit of the
RFC2026 Variance Procedure, i.e., explain what is being done and
why it is being done and to put their AD "jobs" on the line when
doing so. Whether explicit or not, I think ADs assenting to a
final action on a significant procedural change that doesn't
have the sort of support and process behind it that Dave
outlines should be asking themselves whether they are prepared
to resign (not just wait for the Nomcom or a recall that has
become procedurally impossible) if the community doesn't go
along with the action. It should be considered that serious.
Just my opinion.
best,
john