Re: [spring] Dispute process (Was: Resignation request)

[Pete Resnick <[e-mail]>]

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