Subject: Re: My notes from the chairs training sessions

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Dec 2021 13:17:45 -0500

Thank you for the interesting notes.
I had difficulties with the time... 7am was clear, but I was foggy.
1pm was usually in conflict.    I did not feel my time was well used.

Bron Gondwana <[email-masked]> wrote:
    > * Scenario 1 – A recommendation was made and there seems to be agreement among participants in a virtual interim meeting that included some of the more vocal WG participants. What should happen next? What kind of additional interactions need to take place to get to rough consensus?
    > * Luigi, Lars, Bron, Michael Richardson, Christian Amsuss, Maria Ines Robies
    > * Summary email of the decision to the list.
    > * Chairs set a date to receive objections.
    > * What’s important is that the mailing list gets the summary of the
    > decision and why - not a rehashing of all the options.
    > * Point out in meeting that it will be confirmed on the list, and those
    > who were present in the meeting

I think that this part of the part that annoys me the most, but I like what
you captured.   Chairs are empowered to determine consensus, and it is best,
I think, for the chairs to state the consensus that they see, and provide a
date by which to disagree.  Invoke Cunningham's law if you have to.
I really would like chairs to do this for Adoption Calls.
I see no point in +1 from the authors of the document.
If the chairs doubt that there are enough reviewers, then they should state,
"We think that document X is within our charter, and we'd like to adopt it,
 but we don't think there are enough reviewers."

The only time I think that a +1 from authors is useful is if the chairs think
that one or more of the authors are just not really involved.  But, an IPR
check would also reveal that.

    > * examples for IETF working groups?
    > * Examples like: bringing more people into the conversation.  Create an
    > environment where people feel comfortable contributing.  In some of the
    > meetings, a few voices (often the experts) - not a lot of others asking
    > questions, re-framing of what was stated to help people collaborate.

Also, just reaching out and asking people.  "Bob, what do you think?"

    > * One participant in our session switched from busy agenda to lots of
    > time for discussion, which was good.

Yes.

    > hard to judge consensus when the working group is silent.  Are people
    > uninterested, or OK → only the core people are interested.  Other
    > chairs: how do you handle it, particularly remote?

Invoke Cunningham's Law, provide a random, probably wrong, view :-)

    > * “Is this the hill you are willing to die on?” → sometimes can encourage consensus.
    > * ALWAYS set a deadline when confirming the mailing list, so that
    > people have a limit to send.

Yes, but be a bit generous.  People with meeting conflicts might take two-three weeks
before they have time to watch the youtube.
I also assume everyone goes on a 10 day vacation after IETF week :-)
(I never seem to get to...)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Robert Sparks <[email-masked]>
Date: Thu, 2 Dec 2021 14:10:02 -0600

>      > * “Is this the hill you are willing to die on?” → sometimes can encourage consensus.

Is there a way to apply this kind of pressure without using that 
particular idiom?

RjS

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Dec 2021 15:22:20 -0500

Idiom aside (and I agree that it's an unfortunate one), I don't like
the concept:

What that mechanism says to me is that "you" have one (or two, or some
other limited set) of issues you can hold out on, and you have to
choose which one (or ones out of a few) about which you'll dig in your
heels... and you will compromise on the others because you've run past
your limit.

That's not what we're about, I don't think that's what we should be
about, and I'd prefer to discourage that way of thinking about it.

A better way to look at it is whether this issue is worth blocking the
document for.  What's wrong with this solution?  What do you see as
the harm if we choose this?  Are there other solutions than the ones
that have been discussed, where we might find something we can all
accept?  Just *how* unacceptable is this one?

I usually phrase it as, "Can you live with this?", and sometimes, "Is
it more important that this go your way, or that the issue is decided
and we move on with the spec?"

Barry

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Dec 2021 15:48:25 -0500

> about, and I'd prefer to discourage that way of thinking about it.

I agree that this is not an attitude to encourage.

Having said that, people have a limited amount of time and energy (and
"gumption") and it is possible to live with many things, given enough effort
at the implementation stage.
Many decisions are unacceptable to some, but they can't always fix everything.

    > accept?  Just *how* unacceptable is this one?

I think that RFC7282, sections 6 and 7 apply strongly.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 03 Dec 2021 22:53:05 +1100

> I agree that this is not an attitude to encourage.

Thanks everyone!  I agree that it's not a good attitude.  I transcribed this from the discussion in the meeting, and certainly more than one person used the "hill to die on" language.  It's common parlance, and it is indeed not really the attitude we want to foster in the IETF.   It's an underlying concept of "this really matters" rather than "this is my stylistic preference" - and it's often hard to self-reflect enough to know if your objection comes from a place of underlying data or of poorly founded assumption, so some kind of "reflect on how awful it would be if this was the way it was".  Sometimes the objection isn't "this won't work", it's "this will mislead people and many will make obvious mistake[tm] because the design of the protocol makes obvious mistake seem sensible.  The affordances are just wrong".  And that's hard to prove except in the number of protocol experts who have to go around later and call implementation authors idiots later for getting it wrong (see for example the latest DNSSEC shenanigans documented at https://slack.engineering/what-happened-during-slacks-dnssec-rollout/ and the many discussions which ensued all over the internet).

> Many decisions are unacceptable to some, but they can't always fix everything.

Per my initial terminology draft: there are three ways to get to "consensus": persuasion, fatigue and fiat.  As much as possible we want persuasion to win (and yes, I'd love a word starting with "f" for persuasion so it alliterates nicely).  But sometimes we reach consensus by fatigue.  We don't really want to ever reach consensus by fiat (chair declares consensus when the working group doesn't believe it's been reached).

>     > and we move on with the spec?"

Yep - sometimes fiat is the only actual solution, because the alternative is no progress at all.  Otherwise you can DoS the standards process by just standing in the middle of the room and yelling "NO" for the entire meeting.  The "objection must be clear and make sense to others, not just be a no for the sake of blocking something" langauge which I think my notes captured too.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Dec 2021 15:22:22 +0100

On 2021-12-03, at 12:53, Bron Gondwana <[email-masked]> wrote:
> 
> It's an underlying concept of "this really matters" rather than "this is my stylistic preference”

That distinction is less clear-cut that one might think.

Good protocol designers have *taste*.

That taste is shaped and honed over years and decades of seeing what goes wrong in protocol development.  

I mean, nobody would develop a new text-based protocol without availing themselves of a tool such as ABNF?  Right?   Nuff said…

The underlying problem (actually more a feature than a bug) is that collaborative development is done between people who have widely different experiences behind them (not just different levels of experience, but different areas).  It is sometimes hard to argue some point that grew out of experience and has gelled into taste, and the relevant experience may simply not be available to other participants.  Of course it is the job of a collaborator to translate that information as much as possible, but in particular the severity of a violation of important principles is hard to communicate.  Hence some expression of “over my dead body” (another piece of bad language) is occasionally needed.

I wouldn’t mind if we got used to a better way to say this.
MUST NOT GO FORWARD (i.e., better to stop work than to continue this particular way) may be the basis of one of them.

Grüße, Carsten

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 06 Dec 2021 09:19:17 +1100

> Good protocol designers have *taste*.

I see this invoked occasionally and I am forced to disagree.  Taste or intuition is built through experience and is the result of the imprecise way that we translate what we learn into mental shorthands.  Most of what you describe as being rooted in something intangible can be reduced to an application of principle.  Taste, like intuition, can be wired poorly, so it is our responsibility to translate our objections into arguments that are clear and precise.