On 10 Mar 2020, at 17:44, Andrew Alston wrote:
Firstly - let me say this - there are several outstanding, unaddressed
issues in this draft - and the moment that this formally goes into
last call (which it still hasn't left despite the emails from Martin)
that appeal will be coming - that is guaranteed. However, the fact
that this was moved out of last call had very little to do with the
request for the resignation. What triggered this was the fact that
despite mail after mail after mail in the preceding days - within 2
hours of another edition of the draft being published that directly
went to what was being discussed, somehow, consensus was declared.
This denied anyone the opportunity to comment on, digest or respond to
the proposed wording, and the wording was material, it wasn't simply a
syntax change.
So my first question here is whether anyone engaged in the first two
steps of RFC 2026, section 6.5.1
<https://tools.ietf.org/html/rfc2026#section-6.5.1>:
A person who disagrees with a Working Group recommendation shall
always first discuss the matter with the Working Group's chair(s),
who may involve other members of the Working Group (or the Working
Group as a whole) in the discussion.
If the disagreement cannot be resolved in this way, any of the
parties involved may bring it to the attention of the Area
Director(s) for the area in which the Working Group is chartered.
The Area Director(s) shall attempt to resolve the dispute.
The fact is that chairs and ADs do screw up. They are human like the
rest of us, and sometimes the pressure to get something out the door and
done overwhelms correctly following the process and really determining
the consensus. It is our responsibility as IETF participants to throw on
the brakes and say to the chair or AD "I think you blew the consensus
call here. Can we please discuss this?" Sometimes, that doesn't work,
but it's the first step. So, was this attempted before the resignation
request?
Secondly - The original shepherd document did not once - in the entire
document - mention the word consensus outside of where it referred
to the consensus achieved on RFC8200. Instead - it cited a bunch of
+1's as an indication that the document had support. I point out that
this runs totally and utterly contrary to everything stated in
RFC7282.
To be fair, RFC 7282 says:
Note: This document is quite consciously being put forward as
Informational. It does not propose to change any IETF processes and
is therefore not a BCP. It is simply a collection of principles,
hopefully around which the IETF can come to (at least rough)
consensus.
and:
While the community has come to rough consensus that the principles
expressed in this document are (at least approximately) right, many
of our current practices are not consistent with these principles.
Again, this document is primarily intended to generate thought and
discussion, not dictate practices. If the IETF does commit itself
to
these principles, practices may change in the future.
Now I happen to think (and others have told me they do as well) that
following the advice of 7282 is a really good idea. But the community
only came to consensus that 7282 was good "information", not a required
practice. Still, citing a bunch of +1's as an indication of consensus is
not a good sign.
This was flagrant, and blatant abuse of process in my view - and it
was rail roading through a document that both myself and others
dispute there is any form of consensus on.
As I said above, folks in leadership sometimes screw up. "Abuse" seems
to imply malice. I think this is just as easily attributable to (a
really bad) error in judgment.
I do not for one second believe that consensus means we have to agree
on everything, consensus means issues have to be addressed and closed
- they are not - they were still under heavy discussion - and there
are other issues which I have cited on this list, where promises to
address things were made, and never followed through on.
Yup. Again, that sounds to me like good grounds to start the conflict
resolution and appeals process.
So - Why not move straight away and ask for a formal recall process?
Actually, that was never my question. I agree, starting a formal recall
is a pretty big hammer for an error (or a series of errors). The
question I had was why not use the 2026 6.5 process first?
Firstly - I've long believed in transparency - hence, if I am going to
do something, I am going to do it publicly, and I am going to stand by
it - that is in my view absolutely critical in a bottom up
organization.
Although a bit tricky in the case of a request for resignation: The
person in question is just as likely to get dug-in if challenged like
that in public. Again, being humans, people get defensive when publicly
shamed. Personally, if I ever got to the level of thinking that someone
ought to resign, I'd bring it to them privately first. Why do you think
that the public request is "critical"?
Secondly, invoking a formal recall process against someone is a hell
of a thing to do - once started - if recalled - that person has been
formally recalled for the rest of his days. I prefer to give someone
the option of saying "I screwed up" and stepping aside before invoking
such a process...
That I certainly agree with.
I realize that as with many things in life, we may not always agree -
but that being said - the request was transparent, and I still
believe, on the basis of the actions taken by the AD - entirely valid.
Since I have not seen the 2026 6.5 process invoked publicly, I do
question whether the resignation request was appropriate. But as I said,
I'd like to hear more about the progression of events. Was the person
given the opportunity to correct the error? Was the explanation somehow
lacking and therefore required the resignation request?
pr
--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best
