Subject: [spring] Resignation request

From: Sander Steffann <[email-masked]>
Date: Mon, 2 Mar 2020 21:32:53 +0100

Hi,

I am shocked by the declaration of consensus on draft-ietf-spring-srv6-network-programming by Martin Vigoureux. There was much discussion going on about one aspect of the draft, and there was clearly no consensus amongst the participants. There are still questions that haven't been answered about even the applicability of the contested text, let alone addressed. Promised about for example reporting back on the impact on RIR policies have never been fulfilled. And those are just the two bits that concern me most personally.

Steamrolling a draft through a working group completely undermines the whole idea of the IETF and greatly damages it trustworthiness and reliability.  By bluntly declaring consensus despite all of the objections within two hours of the latest version of the draft being published I feel that Martin Vigoureux has lost the credibility as an AD. I strongly feel a resignation is in order at this point.

Cheers,
Sander

---

From: Andrew Alston <[email-masked]>
Date: Mon, 2 Mar 2020 20:38:50 +0000

> On 02/03/2020, 23:34, "ietf on behalf of Sander Steffann" <[email-masked] on behalf of [email-masked]> wrote:
>
>    Hi,
>    
>   I am shocked by the declaration of consensus on draft-ietf-spring-srv6-network-programming by Martin Vigoureux. There was much discussion going on about one aspect of the draft, and there was clearly no consensus amongst the participants. There are still questions that haven't 
> been answered about even the applicability of the contested text, let alone addressed. Promised about for example reporting back on the impact on RIR policies have never been fulfilled. And those are just the two bits that concern me most personally.
>    
>    Steamrolling a draft through a working group completely undermines the whole idea of the IETF and greatly damages it trustworthiness and reliability.  By bluntly declaring consensus despite all of the objections within two hours of the latest version of the draft being published I feel
> that Martin Vigoureux has lost the credibility as an AD. I strongly feel a resignation is in order at this point.

Sadly, I have no option but to second this request.  After hundreds (literally) of emails that were highly contentious that directly relate to the change in question in that document, to declare consensus 2 hours - almost to the minute - after the changed document was published - before anyone has a chance to read - digest or respond to either agree or disagree with the change, is nothing short of mindblowing.  The actions taken in the context of this draft bring in question the credibility of the consensus process as a whole and cast doubt on the credibility of the IETF as a standards body that operates the consensus principle, and as such, I feel they bring the IETF and the process into disrepute.  

In my view, the only option here is to formally request that the AD resign with immediate effect.

Thanks

Andrew

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 2 Mar 2020 20:56:06 +0000

Sander Steffann wrote on 02/03/2020 20:32:
> Steamrolling a draft through a working group completely undermines
> the whole idea of the IETF and greatly damages it trustworthiness and
> reliability.  By bluntly declaring consensus despite all of the
> objections within two hours of the latest version of the draft being
> published I feel that Martin Vigoureux has lost the credibility as an
> AD. I strongly feel a resignation is in order at this point.

There's been a really serious breach of due process here.  The issues 
that cropped up on around draft-ietf-spring-srv6-network-programming are 
subtle and not easily resolved.  What is beginning to emerge as 
consensus is that there are underlying problems with 8200 that need 
examination and careful resolution.

Frankly, it is rather difficult to see how the srv6 draft can progress 
without this clarification.

For sure there's no basis for someone to throw a couple of extra 
sentences into a draft and then for an AD to declare consensus two hours 
later - and before anyone's had the chance to even read the draft.

At the very least, the consensus judgement needs to be rolled back.  I 
respectfully suggest that Martin needs to recuse himself from any 
further involvement with this draft, and that he should consider whether 
his actions are compatible with continuing to be an AD.

Nick

---

From: Sander Steffann <[email-masked]>
Date: Mon, 2 Mar 2020 21:59:12 +0100

Hi Nick,

> At the very least, the consensus judgement needs to be rolled back.  I respectfully suggest that Martin needs to recuse himself from any further involvement with this draft, and that he should consider whether his actions are compatible with continuing to be an AD.

Thank you, that is what I was trying to say. Your words reflect what I wanted to say better than mine.

Cheers,
Sander

---

From: Melchior Aelmans <[email-masked]>
Date: Mon, 2 Mar 2020 22:02:42 +0100

I won't just throw in a +1 ;)

On the serious side; following this discussion closely, I have to agree
that at the least it doesn't feel correct and as if this is the right way
of operating.
It might be correct from a procedure pov but it doesn't feel like it should
go this way.

Thanks Nick for wording it better :)

Regards,
Melchior

---

From: "Job Snijders" <[email-masked]>
Date: Mon, 02 Mar 2020 21:15:59 +0000

Dear all,

The procedure to instantiate what effectively constitutes a resignation is described in 7437 + 8713, specifically https://tools.ietf.org/html/rfc7437#section-7 and https://tools.ietf.org/html/rfc8713#section-7

Keep in mind, this is a different process than an appeal on for instance a decision made regarding a working group's consensus (or lack thereof).

Kind regards,

Job

---

From: Ted Hardie <[email-masked]>
Date: Mon, 2 Mar 2020 13:19:20 -0800

Hi Sander,

Without any comment on this particular instance, it is generally a good
idea to go through an appeal of a specific decision first. My experience is
that people do reconsider their actions in the light of appeals fairly
frequently, and it is generally better to explore the option of
reconsideration before anything else.  If there are still concerns after
that, you can always test the waters for further actions (such as a recall,
which is set out in https://tools.ietf.org/html/rfc7437#section-7 and
https://tools.ietf.org/html/rfc8713#section-7).

Having made many of my own mistakes over the course of my time in the IETF,
I know I have appreciated the opportunity to get something right (or
explain more fully my reasoning.)  I understand that there are other
efforts at drafting a summary of issues in the general space, but a short,
focused appeal of the nature "I ask for a reconsideration of a declaration
of consensus, given the amount of time the most recent draft was available
before its declaration" might prove useful.

best regards,

Ted

On Mon, Mar 2, 2020 at 12:34 PM Sander Steffann <[email-masked]> wrote:

> Hi,
>
> I am shocked by the declaration of consensus on
> draft-ietf-spring-srv6-network-programming by Martin Vigoureux. There was
> much discussion going on about one aspect of the draft, and there was
> clearly no consensus amongst the participants. There are still questions
> that haven't been answered about even the applicability of the contested
> text, let alone addressed. Promised about for example reporting back on the
> impact on RIR policies have never been fulfilled. And those are just the
> two bits that concern me most personally.
>
> Steamrolling a draft through a working group completely undermines the
> whole idea of the IETF and greatly damages it trustworthiness and
> reliability.  By bluntly declaring consensus despite all of the objections
> within two hours of the latest version of the draft being published I feel

---

From: Sander Steffann <[email-masked]>
Date: Mon, 2 Mar 2020 22:30:20 +0100

Hi Ted,

> Without any comment on this particular instance, it is generally a good idea to go through an appeal of a specific decision first. My experience is that people do reconsider their actions in the light of appeals fairly frequently, and it is generally better to explore the option of reconsideration before anything else.  If there are still concerns after that, you can always test the waters for further actions (such as a recall, which is set out in https://tools.ietf.org/html/rfc7437#section-7 and  https://tools.ietf.org/html/rfc8713#section-7).

I hope that email that was all that is necessary. I dislike official procedures against people when not necessary. People make mistakes, and should (must) be given the opportunity to solve them. In this case I feel that part of that solution is a voluntary resignation, but I'm open to alternatives.

> Having made many of my own mistakes over the course of my time in the IETF, I know I have appreciated the opportunity to get something right (or explain more fully my reasoning.)  I understand that there are other efforts at drafting a summary of issues in the general space, but a short, focused appeal of the nature "I ask for a reconsideration of a declaration of consensus, given the amount of time the most recent draft was available before its declaration" might prove useful.

If that was the only thing I object to… Unfortunately I cannot believe an AD can be oblivious of the controversy, and I have seen several attempts to solve the open issues. I am just baffled that consensus can be declared while these attempts are still ongoing.

Let's see what happens now before deciding what to do next.

Thank you for your advice.

Cheers,
Sander

---

From: "Scott O. Bradner" <[email-masked]>
Date: Mon, 2 Mar 2020 16:40:29 -0500

I have no information about the situation but I do not understand why an AD would be declaring consensus in any case - 
that is normally the responsibility of WG chairs.  see RFC 2418 section 3.3 

Scott

> On Mar 2, 2020, at 4:30 PM, Sander Steffann <[email-masked]> wrote:
> 
> Hi Ted,
>

---

From: Sander Steffann <[email-masked]>
Date: Mon, 2 Mar 2020 22:43:25 +0100

Hi,

> that is normally the responsibility of WG chairs.  see RFC 2418 section 3.3 

The only active/available WG chair was a co-author of this draft.

Cheers,
Sander

---

From: "Scott O. Bradner" <[email-masked]>
Date: Mon, 2 Mar 2020 16:46:05 -0500

well, that is a funky situation

thanks

Scott

> On Mar 2, 2020, at 4:43 PM, Sander Steffann <[email-masked]> wrote:
> 
> Hi,
>

---

From: Andrew Alston <[email-masked]>
Date: Mon, 2 Mar 2020 21:47:45 +0000

Contributor - not co-author - but also with 6 drafts that have normative references to the draft in question that could not proceed if this stalled

Andrew

On 03/03/2020, 00:44, "ietf on behalf of Sander Steffann" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    
    Cheers,
    Sander

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 3 Mar 2020 12:32:17 +0000

> On 2 Mar 2020, at 21:43, Sander Steffann <[email-masked]> wrote:
> 
> Hi,
> 

As a WGC that has been in a position where the chairs had a CoI, I(we) asked the WG Secretary to manage the document, and that is what other WGs do. Look at the DetNet data plane drafts as an example. That means that the decision is taken at the lowest level and leaves the AD continue in the oversight role.

Anyway from the discussion on the list this probably need to go for review by the other two RTG ADs to check that they are happy with the decision or to recommend some other action.

- Stewart

---

From: Loa Andersson <[email-masked]>
Date: Wed, 4 Mar 2020 12:30:22 +0800

Stewart, et.al.,

First, there has been some ambivalence regarding what the issue with
an AD taking this type of decission.

- there is no doubt that an AD may take this decision, module enough
   involvement in the wg and giódd understanding of the issues

- it might be discussed if the right decision were taken, from my
   point of view (personal opinion) I can live with this decision

Comment on Stewart's comment inline.

> As a WGC that has been in a position where the chairs had a CoI, I(we) asked the WG Secretary to manage the document, and that is what other WGs do. Look at the DetNet data plane drafts as an examp…

Yes - a much better practice. You could also appoint working group chair 
from another group as "shepherd" and explicitly delegate the task to
call consensus after the wglc.

I think that PALS did this for me once when both chairs were draft
authors.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 5 Mar 2020 08:53:24 -0500

It is not at all unusual for drafts to change AFTER WG consensus has been
reached. The question is whether the changes are within the spirit of what
there is consensus for. So the mere fact that a draft was revised just
before consensus being declared is not in itself evidence of perfidy or a
cause for calling for anyone's resignation.

I am getting rather fed up of the way in which this is being discussed. I
understand that people have deep seated ideological beliefs regarding the
sanctity of what they imagine the Internet architecture to be. But making
public demands for people to resign is not the way to address that.

I also note that the outcome of the architecture discussion I attempted to
provoke was the IP packet purists stating 'you can have your opinion on
architecture but others are entitled to disagree'.

Well hello, that was precisely the point I was making. You cannot preach
'permissionless innovation' and then insist on a single architectural view
being correct. I do not insist that my model is the only correct one, but I
do have at least part of a model that describes the Internet as it is today
and I am not aware of anyone else in the argument having attempted that.

Demanding resignations over disagreements over sacred texts that are not
even written down seems an unreasonable way to behave and I think folk need
to stop it.

For those of you who are interested, this is where I got on the model to
date. As you will note, I explain why layered models do not work and why
the OSI model in particular is unhelpful. But the principles of
encapsulation are still important and we need to understand what the
interfaces between the layers are. And this is especially true for projects
like DNS Discovery and QUIC where we would wish to change those layers.

http://defaultdenysecurity.com/Professional/Architecture/

---

From: Alex Bogdanov <[email-masked]>
Date: Thu, 5 Mar 2020 15:55:02 -0800

Hi,

To add my 2c, I am OK with the declaration of consensus for this
draft. This draft is >2y old and had been the subject of extensive
collaborations on the mailing list, many revisions, many working group
meetings and last call 3 months ago.

I don't think the original email is the right way to express
disagreement(we have a process for that). I also fear that these types of
exchanges are discouraging participation in open technical debates whereas
what we should be doing is encouraging innovation and making progress.

I personally want to thank Martin and Bruno for the diligent and effective
work they've been doing on this draft(and many others) whilst being short
handed. Kudos!

Cheers,

-- Alex

Alex Bogdanov | Strategic NetEng | bogdanov@ <[email-masked]> | Cell:
650-314-8196

On Tue, Mar 3, 2020 at 8:30 PM Loa Andersson <[email-masked]> wrote:

> >>> I have no information about the situation but I do not understand why
> an AD would be declaring consensus in any case -
> > As a WGC that has been in a position where the chairs had a CoI, I(we)
> asked the WG Secretary to manage the document, and that is what other WGs
> do. Look at the DetNet data plane drafts as an example. That means that the
> decision is taken at the lowest level and leaves the AD continue in the
> oversight role.
>
> > Anyway from the discussion on the list this probably need to go for
> review by the other two RTG ADs to check that they are happy with the
> decision or to recommend some other action.
> >
> > - Stewart
> >
> >
>
> --
>
>

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 Mar 2020 10:41:16 -0500

> what we should be doing is encouraging innovation and making progress.

The complaint that started this thread might discourage participation,
but then, so might the cause of the complaint.  The complaint was a bit
incendiary, and that is a problem.  Then again, the process we have for
dealing with complaints is heavily biased against plaintiffs -- which is
probably as it should be, as otherwise we might never get anything done,
but then legitimate complaints don't get heard.  I feel OP's
frustration.

Nico
--

---

From: "Pete Resnick" <[email-masked]>
Date: Tue, 10 Mar 2020 12:11:47 -0500

On 10 Mar 2020, at 10:41, Nico Williams wrote:

> ...the process we have for

Nico, could you (or others) expand on this?

I really think this is worthy of a separate discussion: What is it about 
the current process that you find biased against those who bring up a 
dispute? (I take it we're talking about RFC 2026 section 6.5 
<https://tools.ietf.org/html/rfc2026#section-6.5>.) Have you encountered 
a bias in undertaking such a dispute?

I have no doubt that this process is under-used (as a chair and an AD, I 
had to actively encourage people to use the dispute process instead of 
just giving up), but I've always assumed that it was just people not 
wanting to "rock the boat", or not wanting to be seen as a "complainer", 
or thought that nobody up the chain would take them seriously. Those are 
serious problems and we should be figuring out how to address them, 
since people bringing up failures is the only way we can stop bad things 
from happening when a WG or someone in leadership gets tunnel vision and 
does the wrong thing. However, this is the first time I've heard someone 
express that the process itself is stacked against someone with a 
dispute. If that's true, we should really talk about how to fix that.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: Warren Kumari <[email-masked]>
Date: Tue, 10 Mar 2020 13:55:50 -0400

> dispute. If that's true, we should really talk about how to fix that.

+1.

I realize that +1 is largely content free, but I believe that appeals
and recalls are an incredibly important part of the IETF process -
they are the reason that we can have a process which uses rough
consensus (not voting), and where our process has the flexibility to
(as Spencer would say) "Do the right thing!", and not blindly follow
checklists. In order for these to work, people need to be able, and
comfortable invoking appeals and recalls[0]...

W
[0]: In my copious free time, I still want to organize an exercise
where we fully exercise the recall process - have a pretend AD who
does something outrageous, and then work the entire process (with some
optimizations to not waste everyone's time!)  to fully make sure there
are not any hidden gotcha's. We have worked most of it, and have
thought about it in table-tops, etc - but I'd hate to discover a
hidden issue right when it is most contentions and needed....

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 Mar 2020 13:45:19 -0500

> Nico, could you (or others) expand on this?

Yes.  Challenging consensus is difficult.  People with substantive
commentary sometimes get tanks driven over them.  I've a few stories of
this.  One fairly recent one involving the TLS WG.

> I really think this is worthy of a separate discussion: What is it about the
> current process that you find biased against those who bring up a dispute?

If you get left on the rough side of consensus, whether rightly or
wrongly, and you wish to challenge this, it's really difficult.  You
might have to file an appeal, and if you do you'll annoy and anger
people who want their RFCs published a year ago.

> (I take it we're talking about RFC 2026 section 6.5
> <https://tools.ietf.org/html/rfc2026#section-6.5>.) Have you encountered a
> bias in undertaking such a dispute?

What I've encountered is that at the limit you have to appeal or give
up, and how well things go before you get to that stage depends on how
willing WG chairs and responsible AD are to actively mediate dispute
resolution.

The case I felt went really badly was the TLS DNSSEC extension.  I don't
want to summarize that here because it will be too easy to accidentally
or unconsciously mischaracterize some detail and trigger a flame war.

That case left many palpably angry, including myself.  The resolution of
that case, BTW, was that the WG decided to drop the work item and let
each do their own extension via the ISE.  IMO that is less than ideal
because if it keeps happening then we're going to have a large TLS
extension support matrix and our users will be sad.

There's no easy way to challenge a consensus to drop a work item.  What
are you gonna do, appeal asking the IAB to force a WG to take on a work
item it doesn't want to?  A WG could even conclude out of spite if
forced to do something it doesn't want to.

So there was no question of appeal, really.  But I do feel that the
chairs and responsible AD did not help enough ahead of the WG throwing
its hands up in the air -- that might be an incorrect perception though,
as maybe the chairs and AD were simply unable to get the strongest
personalities on either side of the dispute to compromise, but, too, I
think they could have called the consensus rather than wait till the WG
threw in the towel on the work item.

> I have no doubt that this process is under-used (as a chair and an AD, I had

I've reached out to chairs and ADs a number of times before, and that
has worked, and can work where they're willing to.

It's difficult to go beyond that to appeals.  We do have to be done at
some point with any one work item.  There is good will to tend to.

The OP of this thread's parent thread clearly felt much more strongly
about their case than anyone did about the TLS DNSSEC extension.  No one
in the latter case felt so aggrieved as to post a "resignation request".

> to actively encourage people to use the dispute process instead of just
> giving up), but I've always assumed that it was just people not wanting to
> "rock the boat", or not wanting to be seen as a "complainer", or thought

There is definitely some of that.

Or at some point a party gets exhausted and gives up.

Some of this is that we're a somewhat academic bunch (RFCs count as
papers now, no?) and you know how it is with academics: the lower the
stakes the worse the infighting.

> that nobody up the chain would take them seriously. Those are serious
> problems and we should be figuring out how to address them, since people
> bringing up failures is the only way we can stop bad things from happening
> when a WG or someone in leadership gets tunnel vision and does the wrong
> thing. However, this is the first time I've heard someone express that the
> process itself is stacked against someone with a dispute. If that's true, we
> should really talk about how to fix that.

Not sure how to make it better, except maybe thus: it should be possible
to get a review of how a dispute was resolved not so much as an appeal,
but as a way to remediate problems to help alleviate _next_ dispute.

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Tue, 10 Mar 2020 15:07:53 -0400

On Mar 10, 2020, at 14:45, Nico Williams <[email-masked]> wrote:

> The case I felt went really badly was the TLS DNSSEC extension.  

I agree and while that case was bad, what’s worse is that no post-mortem was done here. I don’t think the IETF as an organization will take any lesson from this, and that in itself makes it likely the same mistakes will be made again.

> So there was no question of appeal, really.  

I think also because in the appeal some of the same actors would appear. 

> but as a way to remediate problems to help alleviate _next_ dispute.

Going back to this thread, when I read the subject of resignation and the first email, it seemed like I just stumbled across a hallway fight - people that demand unreasonable things. I don’t know how this conflict went from nothing to asking for someone’s resignation but clearly more people should have been involved earlier to de-escalate this. maybe that was tried and just not visible here? It would be good if there had been some kind of log that could have been referenced so we could determine why this failed to de-escalate.

Paul

---

From: Andrew Alston <[email-masked]>
Date: Tue, 10 Mar 2020 21:44:41 +0000

So,

As one of the people that openly supported the original request for resignation by Sander - I felt that - it may be helpful to understand from my side *why* I so strongly supported it - and why I believe, still, that it was a fair option.

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.

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.

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.  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.  

So - Why not move straight away and ask for a formal recall process?  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.  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 - and that is not to say that there will NOT be a formal recall request coming - in fact - its under heavy consideration for both what happened in this instance and for other reasons that have been raised since that request for resignation went out.  

I know that many will go - follow the process - and as I said, I for one, am quite happy to do that, but I believe that giving someone the option to step aside before you institute such process against them is actually the kinder option, and is no less public than a formal recall request would be, since in the spirit of transparency, any such formal request would almost certainly be as public as a request to resign, made so either by IETF process or by the initiators of said process. 

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.  

Andrew

-----Original Message-----
From: ietf <[email-masked]> On Behalf Of Paul Wouters
Sent: Tuesday, 10 March 2020 22:08
To: Nico Williams <[email-masked]>
Cc: Alex Bogdanov <bogdanov=[email-masked]>; SPRING WG List <[email-masked]>; IETF <[email-masked]>; Pete Resnick <[email-masked]>
Subject: Re: Dispute process (Was: Resignation request)

> Not sure how to make it better, except maybe thus: it should be 
> possible to get a review of how a dispute was resolved not so much as 
> an appeal, but as a way to remediate problems to help alleviate _next_ dispute.

Paul

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Mar 2020 10:54:36 +1300

Nico,
On 11-Mar-20 07:45, Nico Williams wrote:
> might have to file an appeal, 

Well yes. There's no way round that - you're on the losing side, which
has been a bad deal throughout human history. But at least there *is*
an appeal process (which in practice there wouldn't be, if we used
majority voting to make decisions). That doesn't indicate bias in
the process.

> and if you do you'll annoy and anger

Again, that doesn't indicate bias in the process.
 
> willing WG chairs and responsible AD are to actively mediate dispute

Of course. But isn't that exactly why the appeals process exists? To
put pressure on chairs and ADs to mediate? I assure you that it's
much more uncomfortable for them to handle a formal appeal than
to try mediation.

I'll stop there because I have precisely zero knowledge of the case
you cite.

    Brian

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 Mar 2020 18:34:43 -0500

On Tue, Mar 10, 2020 at 03:07:53PM -0400, Paul Wouters wrote:
> I agree and while that case was bad, what’s worse is that no
> post-mortem was done here. I don’t think the IETF as an organization
> will take any lesson from this, and that in itself makes it likely the
> same mistakes will be made again.

+1.

Perhaps we need a procedure for lodging complaints that aren't appeals,
and which result in a review and report.

> I think also because in the appeal some of the same actors would appear. 

The whole point of an appeal is to get the IETF chair, or the IAB, to
step in.  The route to appeal was mooted by the WG's choice to abandon
the work item.

(A cynic might wonder if that choice was not purposeful, precisely to
allow the original work to continue unimpeded [perhaps] on the ISE track
with an appeal mooted.  I do not believe that was the case.)

> Going back to this thread, when I read the subject of resignation and
> the first email, it seemed like I just stumbled across a hallway fight
> - people that demand unreasonable things. I don’t know how this
> conflict went from nothing to asking for someone’s resignation but
> clearly more people should have been involved earlier to de-escalate
> this. maybe that was tried and just not visible here? It would be good
> if there had been some kind of log that could have been referenced so
> we could determine why this failed to de-escalate.

+1

I wouldn't want to drag the ombudsman into this, but maybe that's the
next best step.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 Mar 2020 18:55:25 -0500

> Again, that doesn't indicate bias in the process.

It is a bias in the process.  And rightfully so IMO.  The point is that
to get relief requires sufficient motivation to seek it via an appeal.

Q: How many appeals have there been, and how many have succeeded?

But perhaps we can do post-mortems as a lighter-weight relief process,
where a reversal isn't the goal, but that a) it be determined if there
were errors (or perhaps harassment by the people complaining! it goes
both ways) and b) some chastisement.

> much more uncomfortable for them to handle a formal appeal than

But there is a social dynamic.  Appeal and become the bad guy, lose good
will, lose friends, and find your future participation affected.  We're
talking about people who must have their RFCs published!

> I'll stop there because I have precisely zero knowledge of the case

That's fair, and it would be best if we didn't discuss it in this thread
anyways -- its details are not germane, but that such a case exists in
the broad strokes I used to describe it, is germane to the point that
the process of obtaining relief is costly and non-trivial.

I'd settle for not having that happen again than for getting a do-over
with an appeal.

Nico
--

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Mar 2020 13:23:17 +1300

On two specific points:

On 11-Mar-20 12:55, Nico Williams wrote:
...
> Q: How many appeals have there been, and how many have succeeded?

Officially, the history is at:

https://www.ietf.org/standards/process/appeals/
https://www.iab.org/appeals/

I think a lot of the responses are midway between "success" and "failure".
 
> But perhaps we can do post-mortems as a lighter-weight relief process,

On the surface that's an attractive idea, but if it is to be taken
seriously it would need just about as much work as an appeal.

     Brian

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 10 Mar 2020 19:27:47 -0500

All you have to do is ask :-)

That's the awesome part about appeal transparency.

> Q: How many appeals have there been, and how many have succeeded?

This isn't as readable as it was before the website redesign (IMO), but
https://www.ietf.org/standards/process/appeals/ lists the appeals to the
IESG and the IESG response. I'd note that "succeeded" isn't binary - there
are multiple responses that aren't thumbs up/thumbs down - but everybody
knows what happened.

The appeals that make it to the IAB are at https://www.iab.org/appeals/.
I'd note that the IAB tends to say "the IESG didn't think about X, so they
should try again", rather than "what the IESG should have done was Y". But,
again, everybody knows what happened.

I hope that's helpful.

Best,

Spencer

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 Mar 2020 21:05:51 -0500

> I think a lot of the responses are midway between "success" and "failure".

I'll take a look, thanks.  (I have looked here before, but never made a
tally of results.)

> seriously it would need just about as much work as an appeal.

Perhaps so, but it might be more appealing (punny) than appealing on
account of it being less disruptive to the work in question.  Moreover,
an ombudsman could conduct a review with relatively little effort on the
part of the participants.  The outcome would be a report, not a
potential reversal or rehashing of past decisions, but future behavior
might be modified.

Nico
--

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Mar 2020 23:46:40 -0300

On 10/3/20 14:55, Warren Kumari wrote:
[...]
> comfortable invoking appeals and recalls[0]...

Agreed.

In that light, may I ask that question #10 of 
https://www.ietf.org/chairs/document-writeups/document-writeup-working-group-documents/ 
  be rephrased to something else?

At least for non-native English speakers, the phrase "Has anyone 
threatened an appeal" gives Appeals a very negative connotation...

(Is a formal update to RFC4858 needed for that?)

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Pete Resnick" <[email-masked]>
Date: Tue, 10 Mar 2020 23:54:03 -0400

On 10 Mar 2020, at 14:45, Nico Williams wrote:

> commentary sometimes get tanks driven over them.

It is difficult, and I have seen those tanks in the past. What I would 
say is that we've gotten to a point where dispute resolution and appeals 
are seen as such a big deal that people definitely get their armaments 
going quickly. I'm hoping this discussion can give us (participants and 
leadership) some paths back to being a bit more sane about this. More 
below.

> people who want their RFCs published a year ago.

This to me says that we've got to start dealing with the disputes 
earlier in the process to avoid the "annoy and anger" part (though 
sometimes that will be unavoidable). At the time of the WG decision, 
before anything goes to the IESG, it's time to have a discussion with 
the chair. That's before 2026 6.5.1 imagines it, but I don't think 
that's a problem for the first steps.

> willing WG chairs and responsible AD are to actively mediate dispute

Framing the discussion in the terms that 2026 uses is a good idea: 
Either "my views have not been adequately considered by the WG", or "the 
WG has made an incorrect technical choice". I'd start off with, "I think 
you may have blown the consensus call on this point. I'd like to discuss 
that." Not accusatory or angry, just stating the facts. If the chair 
reacts badly to that, let the AD (and perhaps some others) know. All of 
us who chair should learn how to deal with such comments calmly and 
seriously. If you and the chair both take it seriously, it can only 
improve the output of the WG for the chair to consider it.

> forced to do something it doesn't want to.

You're right that forcing the WG to do work isn't feasible. But I could 
imagine other choices. Not knowing the specifics, though, I don't want 
to speculate on what might have worked.

> threw in the towel on the work item.

I think you're probably right. I know I've chaired in the past when I 
didn't see the signs of bad things happening and failed to get out in 
front of it. But the appeal, even if fruitless in the end, would have at 
least made the chair, the AD, and IESG do a bit of post-mortem to figure 
out what went wrong, so we should figure out some way to make them less 
painful (as per your last paragraph).

> has worked, and can work where they're willing to.

That's good to hear.

> some point with any one work item.  There is good will to tend to.

On a technical point where someone feels that the WG truly failed to see 
a serious problem, it's worth certainly worth doing. But even in the 
more process cases, where it was a blown consensus call, I do think it's 
worth going through, even if it doesn't change the outcome for any 
particular work item and is just for post-mortem purposes.

> in the latter case felt so aggrieved as to post a "resignation 

Yeah, I'll reply to Alan after this. I think the case should also be 
instructive.

> There is definitely some of that.

I did a little review some time ago of the appeals brought to the IESG. 
Approximately half of them were perfectly well-reasoned appeals made by 
serious people in the community, and as I remember in the majority of 
them the IESG said, "Oh, yeah, that wasn't a good outcome; let's fix 
it." The approximately other half of the appeals were made by a small 
number of people who I'd call "serial appealers". It's the latter half 
that makes people feel like complainers (by joining that club), but if 
you remove those folks, I think you'll find the outcome of the process 
is pretty good and nobody will call you a complainer for it. (No, I will 
not reveal my criteria for deciding between the two halves. Left as an 
exercise for the reader.)

> Or at some point a party gets exhausted and gives up.

That, of course, is a horrible outcome and what we need to fix.

> stakes the worse the infighting.

As a recovering academic, I know what you mean.

> possible

Absolutely. Every IETF plenary, the chairs have a lunch meeting on a 
variety of topics. Doing something like this as a regular topic (and 
revealing the conclusions to the community) would be a great idea. That 
said, I'm still hopeful we can make the dispute resolution and appeals 
process better than it is now.

pr

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 Mar 2020 00:50:48 -0500

> that's a problem for the first steps.

Fair enough.

> > What I've encountered is that at the limit you have to appeal or
> > give up, and how well things go before you get to that stage depends
> > on how willing WG chairs and responsible AD are to actively mediate
> > dispute resolution.
> 
> Either "my views have not been adequately considered by the WG", or
> "the WG has made an incorrect technical choice". I'd start off with,
> "I think you may have blown the consensus call on this point. I'd like
> to discuss that." Not accusatory or angry, just stating the facts. If
> the chair reacts badly to that, let the AD (and perhaps some others)
> know. All of us who chair should learn how to deal with such comments
> calmly and seriously. If you and the chair both take it seriously, it
> can only improve the output of the WG for the chair to consider it.

There are ways in which chairs and authors can engage in all sorts of
passive-aggressive behaviors that are difficult to pin down.  E.g.,
someone makes a substantive comment during WGLC, WGLC ends, and then no
write-up ensues, nor consensus calls on the issue, for weeks.  When you
finally twist the chairs' arms into calling for consensus then they
don't call it for a while.  Then at some point the commenter is to blame
for delaying the I-D's progress.

At what point in such a sequence would one reach out to the AD?

Delays of that sort happen all the time for non-nefarious reasons, and
we all prefer not to be accused of nefarious reasons for such delays.
If one were to reach for an AD every time there was such a delay... then
at the very least one should also never be the source of such delays,
for example, and anyways, one may quickly be relegated to the PITA list.

The SAA function may well teach us all how to engage in aggressive
behavior that superficially passes for acceptable.

> > There's no easy way to challenge a consensus to drop a work item.
> > What are you gonna do, appeal asking the IAB to force a WG to take
> > on a work item it doesn't want to?  A WG could even conclude out of
> > spite if forced to do something it doesn't want to.
> 
> You're right that forcing the WG to do work isn't feasible. But I
> could imagine other choices. Not knowing the specifics, though, I
> don't want to speculate on what might have worked.

Technically speaking it was the chairs calling the WG's consensus to
drop the work item.  That decision would be subject to appeal, but we
felt an appeal was not worth the trouble (but see below), and that that
decision would be mode difficult to prevail on on appeal than the
alternative adverse decision that we were in the rough.

> > chairs and responsible AD did not help enough ahead of the WG
> > throwing its hands up in the air -- that might be an incorrect
> > perception though, as maybe the chairs and AD were simply unable to
> > get the strongest personalities on either side of the dispute to
> > compromise, but, too, I think they could have called the consensus
> > rather than wait till the WG threw in the towel on the work item.
> 
> front of it.  But the appeal, even if fruitless in the end, would have
> at least made the chair, the AD, and IESG do a bit of post-mortem to
> figure out what went wrong, so we should figure out some way to make
> them less painful (as per your last paragraph).

Aha.  The appeal process _is_ the only post-mortem process we have.

> > has worked, and can work where they're willing to.

IMO the process works well most of the time.

> > It's difficult to go beyond that to appeals.  We do have to be done
> > at some point with any one work item.  There is good will to tend
> > to.
> 
> On a technical point where someone feels that the WG truly failed to
> see a serious problem, it's worth certainly worth doing. But even in
> the more process cases, where it was a blown consensus call, I do
> think it's worth going through, even if it doesn't change the outcome
> for any particular work item and is just for post-mortem purposes.

Ok.

> I did a little review some time ago of the appeals brought to the
> IESG.  Approximately half of them were perfectly well-reasoned appeals
> made by serious people in the community, and as I remember in the
> majority of them the IESG said, "Oh, yeah, that wasn't a good outcome;
> let's fix it." The approximately other half of the appeals were made
> by a small number of people who I'd call "serial appealers". It's the
> latter half that makes people feel like complainers (by joining that
> club), but if you remove those folks, I think you'll find the outcome
> of the process is pretty good and nobody will call you a complainer
> for it. (No, I will not reveal my criteria for deciding between the
> two halves. Left as an exercise for the reader.)

There are rather few appeals on record.  Lately they happen less than
yearly.

> That, of course, is a horrible outcome and what we need to fix.

If they were right, sure.  It's tempting to conclude that being
exhausted is an admission to being wrong.  If a crowd of usual suspects
(aren't must of us members of such crowds at IETF?) can muster loud and
repeated assertions that the complainant is wrong, it can start to seem
like they're right, and the other party will get discouraged.

> > possible to get a review of how a dispute was resolved not so much
> > as an appeal, but as a way to remediate problems to help alleviate
> > _next_ dispute.
> 
> Absolutely. Every IETF plenary, the chairs have a lunch meeting on a variety
> of topics. Doing something like this as a regular topic (and revealing the
> conclusions to the community) would be a great idea. [...]

Sure, but who shall bring up a particular dispute at that meeting, given
that it's ex-parte?

>                                               [...]. That said, I'm still
> hopeful we can make the dispute resolution and appeals process better than
> it is now.

Just how busy is the ombudsman anyways?  Maybe we can give them more to
do.

Nico
--

---

From: "Pete Resnick" <[email-masked]>
Date: Wed, 11 Mar 2020 13:16:16 -0500

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

---

From: "Pete Resnick" <[email-masked]>
Date: Wed, 11 Mar 2020 13:26:35 -0500

On 10 Mar 2020, at 18:34, Nico Williams wrote:

>>> give

Adding a "report back" step to the less formal part of RFC 2026 6.5.1 
would probably be a good practice. I know I did do this when an issue 
was "semi-formally" brought to my attention some years ago.

> step in.  The route to appeal was mooted by the WG's choice to abandon

Again, remember that there's a less formal part, before the chair, whole 
IESG, or IAB step into the picture. That might have been the appropriate 
move in this case.

> with an appeal mooted.  I do not believe that was the case.)

As Paul alluded to, it all assume that the ISE accepts the documents. If 
not, more fun may occur.

>> we could determine why this failed to de-escalate.

Yep.

> I wouldn't want to drag the ombudsman into this, but maybe that's the

I would refer you to RFC 7776. I don't think this would be in the 
ombudsteam's purview. (Not trying to get out of work, really!)

pr

---

From: Nico Williams <[email-masked]>
Date: Wed, 11 Mar 2020 15:57:19 -0500

> As Paul alluded to, it all assume that the ISE accepts the documents. If

There was agreement that the WG would not oppose the two parties'
submissions to the ISE on the topic.

> ombudsteam's purview. (Not trying to get out of work, really!)

I was suggesting updating that, not acting as though we already have :)

Nico
--

---

From: "Pete Resnick" <[email-masked]>
Date: Wed, 11 Mar 2020 16:42:37 -0500

> I was suggesting updating that, not acting as though we already have :)

Uh...I think we have enough on our plate. :-)

pr