Minutes interim-2020-gendispatch-03: Mon 11:00
minutes-interim-2020-gendispatch-03-202009071100-00

# Gendispatch Interim
Monday 2020-09-07 11:00-13:00 UTC
Chairs: Francesca Palombini, Pete Resnick

Recordings: https://youtu.be/fvQEOOOp_wk

Jabber Log: https://www.ietf.org/jabber/logs/gendispatch/2020-09-07.html

Minute takers: Francesca Palombini

## Bluesheet

1. Francesca Palombini, Ericsson
2. Pete Resnick, Episteme
3. Keith Moore, Network Heretics
4. Dhruv Dhody, Huawei
5. Barry Leiba, Futurewei
6. Maja Andjelkovic
7. Juliana Guerra, Derechos Digitales
8. Peter Van Roste, CENTR
9. Bron Gondwana, Fastmail
10. Rich Salz, Akamai
11. Jay Daley, IETF Administration LLC
12. Adrian Farrel, Old Dog Consulting
13. Viktor Dukhovni
14. John Border, Hughes
15. tale
16. Colin Perkins, University of Glasgow
17. Mirja Kühlewind, Ericsson
18. Andrew Campling, 419 Consulting
19. Rob Wilton, Cisco
20. Kyle Rose, Akamai

## Agenda & Minutes

### Chair intro (5 minutes)

#### This is an IETF meeting

* [Note well](https://datatracker.ietf.org/submit/note-well/) applies.
* This meeting is recorded.
* Presence is logged (please sign the bluesheet).

#### Reminder: we are looking to answer the dispatch question.

- The discussion on content should be kept on the lines of if/what the IETF
should work on, as that impacts the "where". - We are not trying to solve the
problem, we are trying to figure out what part of this area the IETF should
work on. - Helpful: what would be a satisfactory output to the discussion (BCP,
informational, updates to the RFC Style Guide, changes to the idnits tool,
Gen-Art review guidelines, something similar to W3C manual of style:
https://w3c.github.io/manual-of-style/#inclusive, ...) - we have gone through
minutes [1], jabber logs [2], and gendispatch mailing list discussion
(including the thread starting at [3]) and tried to summarize the discussion
here (see below)

#### Summary from Interim 1 ([see
minutes](https://www.ietf.org/proceedings/interim-2020-gendispatch-01/minutes/minutes-interim-2020-gendispatch-01-202009012000-02))

* People in the room started from "probably AD sponsored", but there was a
shift as the session went on and things were starting to lean towards a BoF or,
with even a bit more support, a WG.

* There were still a few people who thought the work should not progress.

* We did not get a good sense for which of the choices (reject, AD-sponsored,
BoF/WG) people felt, "I definitely want this one and I can't live with the
others" vs. "this is my preference, but I can live with this other one". We'll
be listening for those comments on Monday, and on the list after we post the
summary of Monday's session.

* The opinions were quite varied on the particular documents. It seems that
everybody had some complaints about each document, and that most people had
some support for some sections of all of the documents. We are going to want to
suss out what recommendation the group is going to make for which document(s)
to start with (if any) if the consensus is for the work to move forward.

* There was a good deal of support for some other kinds of activities (IAB
program, other discussion venues), but those seemed independent of the
document-related issues above.

### Terminology proposals:

* Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs -
Mallory
        https://tools.ietf.org/html/draft-knodel-terminology-04
    [-
    slides](https://www.ietf.org/proceedings/interim-2020-gendispatch-01/slides/slides-interim-2020-gendispatch-01-sessa-draft-knodel-terminology-00)

* Effective Terminology in IETF drafts - Bron
        https://tools.ietf.org/html/draft-gondwana-effective-terminology-01
    [-
    slides](https://www.ietf.org/proceedings/interim-2020-gendispatch-01/slides/slides-interim-2020-gendispatch-01-sessa-draft-gondwana-effective-terminology-00.pdf)

* Avoiding Exclusionary Language in RFCs - Keith
        https://tools.ietf.org/html/draft-moore-exclusionary-language-00
    [-
    slides](https://www.ietf.org/proceedings/interim-2020-gendispatch-01/slides/slides-interim-2020-gendispatch-01-sessa-draft-moore-exclusionary-language-00)

### Discussion

Bron Gondwana: +q in chat to join the queue. Not updated my draft yet, I know
the security considerations especially need work. Would like to find a
consensus between the 3 drafts, because I think IETF needs a consensus draft.
Don't think my draft is anywhere near the final stage.

Keith Moore: Starting point to the main product should be the github page
https://github.com/ietf/terminology. If we end up with a BCP, the subject of
the BCP should be how that page gets maintained: maybe there is a committee
that edits that page, how is that committee appointed, to what extent is that
page policy. I'd like it advisory only. The page is where we should focus the
attention, and it allows participation from many people.

John C Klensin: Agree with Keith. This discussion has been very useful in
raising awareness. These are sensitive and important issues and reviewing
drafts is useful. I want to encourage people reviewing the document to go to
the authors and say "this language needs tuning", which I think is necessary
and sufficient. List of strings to replace might distract and discourage from
the work being done.

PR: Please keep in mind the dispatch question.

Andrew Campling: Bron's is the right starting document. Github would be the
wrong place to do something, maybe use something more open. RFC8890 - parallel
with this work. Document that sets out that material published by the IETF
should use inclusive language it's all we need, agree with John we don't need a
long list of terms.

Bron: Agree with Keith that working on the github resource (not necessarily on
github) seems like the right place. How we manage that is the difficult part. 
"internet is for the users": does this necessitate some kind of update to
admission. Bigger issue, but I think we should adress it, or explicitely decide
not to.

John: Mostly agree with the last two speakers. Rather than only having the
option of "where we dispatch this to" we need to have the option of "we're
done, let's move on".

PR: If we go forward with github or some other place, someone has to write down
where that is and what's going on. Are you saying we can do this as an informal?

John: It is not a conclusion that the ouptut needs to be more meeting and more
discussion. We need to have an option "good idea to have had this discussion,
we have all the procedures in place that we need, let's move on".

PR: Slightly different option than "Let's not do it", we know where we are
going, let the ADs deal with it.

John: Declare success and stop.

Viktor: question for Bron and Keith: if there is going to be a github page,
what kind of thing do you envision there? Suggested positive wordings? Useful
content? Are we trying to list forbidden words or are we suggesting alternative
words?

Bron: suggested alternative language

Keith: when I was talking about github page, I didn't mean it should stay on
github. Mostly giving advice rather than listing terms. Does not hurt to have
examples. I'd want to have it to be very clear that these are advices and
suggestions, not forbidden words. Try to ecourage the community to write
documents with these considerations in mind.

Rich Salz: github page is good, but concerned that this is the one time that we
publish things that aren't RFC.

Barry Leiba: we do have precedence, the Tao of IETF. This is something that
will change frequently. Like an IANA registry but not in IANA.

Keith: Agree with Barry. This should not be seen as formal as an RFC. This is
not a standard, this is advice. Frequency of update: I think it should be once
a year, we could have a meeting about updating it.

Bron: Agree with Rich. I take Keith's point about the update frequency. I don't
think we'll update that frequently after the first updates. Don't think going
to cost it a lot to publish it as RFC. Question if it's going to be trusted as
RFC, don't think that's going to make a difference. Don't think it makes a
difference, I am in favor publishing it through our publishing stream.

Viktor: the whole context in which we are working here is language shift and
language changes. I am skeptical of the stability of an RFC. I also fear that
an RFC lends the negative connotation of deviating from a standard too much
weight. This should be aids to authors who might not be aware. This is not a
huge problem in IETF, I am surprised how much time we are spending on this.
What we have is potentially just some lack of guidance, and guidance does not
need to be so heavyweight.

Rich: I don't think the analogy with the Tao holds. We have RFC on other
considerations (Security etc). I think it should be in RFC because that's how
we publish things.

Bron: Replying to Viktor: we should make sure that the draft uses positive
language and may and should instead of MUST, and at that point it's no
different than other documents. It doesn't make a difference where we publish
it. Things in IETF website are taken as seriously as RFC. I like immutable
records.

PR: For those that think that some sort of RFC would be good, RFC stating what
this is about is what we want and then the list of terminology would be
somewhat independent?

John: If we have a list of terminology in an RFC we are going to expose the
IETF ignorance and insensitivity for the list of terms we haven't picked up.
Unfortunate for the IETF to go down this path. If we codify and solidify this
an an IETF policy, it's going to be the source of another debate like this one
or dismissive behavior towards somebody's position. I'm trying trying to
navigate this topic to keep the IETF focused on its technical work, rather than
getting dragged down in this discussion, no matter how important this
discussion is - and I agree it is important.

PR: If there is going to be an RFC should not have a list of terms?

John: If there is an RFC it should talk about broad principles and importance
of this issue, absolutely should not vocabulary or alternatives.

Andrew: Informational is what is needed here. Agree with John, focus on
principles. Can we dispatch to IAB?

PR: We can if they will take it. Mirja in jabber chat is that 8890 came out of
IAB so it could not be a BCP, which is why it's an informational.

FP: To John: where would the content of this RFC should be discussed, where we
dispatch this work?

Bron: John raises the problem with the list. Hard problem. Easy way to solve it
is to not have a list. Principles with the github link would make people happy?
I would be.

Keith: Immediate thing we need to decide is "how does this document (github)
get maintained". We want to move this where it gets the appropriate amount of
attention - not too much but enough - where people can send comment to, that
makes recommendations that are non-binding. If IAB wants to do that, or
separate group. At some point we need a proposal of how to do it. Possible
gendispatch conclusion: entertain proposals in the ml how it gets maintained.

PR: Only good agenda item for gendispatch is one that is gone. Gendispatch
could say form ML, have a quick BoF, and assign some people to get an RFC on
the principles.

Keith: Don't do that, it needs to come from the bottom down up.

PR: someone needs to set up where it's going to take place.

Keith: would gendispatch make recommendations about that?

PR: Yes.

Viktor Dukhovni (from webex): Agreed with Andrew and John.

John: where to dispatch: to nowhere. If there needs to be more discussion, on a
document basis and informal basis, for inclusivity it needs to be IETF list.
And if IETF list is not inclusive enough, we have much bigger problems.

PR: If there has to be further discussion, you'd rather have it on the ietf
list.

John: On a document by document basis, in context, until the colture adjust
itself to better use of terminology. I believe we don't have a major problem
here, and if this is a relatively infrequent problem we need to do it on a
informal correction basis and on a private comments to authors basis unless
there is a rejection from the authors.

Andrew: Problem with dispatching nowhere, even if I agree with John and Bron
that this is not a big problem, is that it sends a message. Dropping it would
be the wrong approach. Putting it back to the ml would also unhelpful. Some
activity is required.

Keith Moore (from webex chat): agree at least to the extent that we need to be
seen as doing _something_. hopefully something minimal

Rich: Agree that taking back to the ietf list is not productive. To John:
asking that those who are offended or harmed take on the responsibility is not
a good thing and tends to not work well.

Bron: Would not be productive in the IETF list, it needs to be done by people
who are willing to show up and do the work. Another list advertised widely. The
most important thing here is that we want to send a welcome signal to people.

Klensin (from jabber) [13:50]:
suggestion of the IETF list is precisely because everyone recognizes it would
not be productive.  But another list is inherently discriminatory against those
who decide to devote limited IETF time to substantive technical work.  And, no,
I wasn't suggesting that those who are marginalized should be the _only_ ones
to defend themselves either.

John: Very concerned about any ongoing formal discussion turning into an
activity that would block people doing technical work and bog things down in
language discussions among those who care deeply, excluding those who are most
affected.   My perception may be wrong, but my sense is that the conversations
in the IETF that most easily go into loops with people repeating themselves
rather than listening to what others are saying and thinking before responding,
and that most swiftly turn toxic are ones in which there is no expectations of
specialized expertise and everyone has an opinion nonetheless.  I am concerned
about setting up structures that encourages those kinds of interactions and
concerned about having people having to chose between participating in
technical discussion or on, for example, language and inclusion discussions. 
The reason for advocating of doing this on a document basis is that the most
frequent problem that might come up in practice is that when we are doing a
revision on a document that use old terminology, and at that point we are going
to have a discussion about retaining terminology which is offensive. For new
documents it is appropriate to discuss terminology, better if on private
communication to the authors. I don't see how to do this not on a document
basis.

Keith Moore (from webex) [13:49]
I wouldn't describe it as having offended people "take on the responsibility",
but I do think that having people who aren't in the position of being offended
act as proxies for those who supposedly are offended, is a recipe for disaster.

Rich Salz (from webex) [13:51]
I understand, but for the safety of those people, it might be the best we can
generally do. "Blame the victim" is far too common, even in this topic as we've
seen.

Kyle Rose (from webex) [13:52]
Bron, what you just said (something like 'the IETF's primary purpose is to
produce high-quality technical standards, not to represent global
demographics'; I should probably watch the recording to transcribe what he
actually said) should be added verbatim to the document. Well said.

Keith Moore (from webex) [13:52]
we want to figure out how to make it easier / more attractive for more diverse
people to show up. we really need for IETF standards to have input from a wider
variety of people, from a wider variety of cultures and conditions.

Rich Salz (from webex) [13:52]
++Keith

Viktor: The idea that we would stay entirely unaware is not credible. The
feedback would come forward one way or another.

PR: Others have said that if the feedback comes from others than those who were
offended, that is somehow not credible.

Viktor: Credibility goes down if people are speaking for a generic hypothetical
class of people. Indeed, some people might be so shy that they might not want
to engage, and that's fine if they find a proxy.

Andrew: read a post in ietf mailing list from academic, they receive a message
from someone saying that a specific group should be offended and the specific
group wasn't. Representing a group of people without first hand experience was
nonsense.

Rich: We are trying to be more inclusive. The concern is that people are not
even here at the table. We don't have to have a prescriptive list. But if we
don't even try to be inclusive, they're never going to be here. I disagree that
we will get feedback from them.

Robert Wilton: About the word list. As a reviewer, I think it is useful to have
a list of words to warn or advice people, potentially with the description of
why. I see the concern. I thik IETF should be sensitive of that industry trend.

Bron: Rich - people who pushed back against the language stuff were not the
western university educated people. Who are we excluding here?

John: We need to open up to private conversations for this to work. I recognize
Robert's comment and appreciate it, but re Bron we better make certain that if
we are doing that we are not deciding this problem is all about people whose
skin is slightly darker or the education slightly different than the collection
of the people on this call. And the comment that someone from a different
cultural environment (who was against) was shouted down is precisely what I am
worrying about doing this by list and committee. Re Bron's comment - one could
be talking about people with big noses. And if you don't understand the
reference, that makes my point.

Juliana Guerra (from webex): I agree with Rich's last comment. There are a lot
of barriers for people potentially offended by this kind of exclusionary
language to give any feedback on any IETF document. And just a few people is
now participating on the discussion.

Viktor: I agree that there is people that do not participate. The reason why
they are not here is that participation is luxury activity - costly in time,
emplyer support and money.

PR: Women that do not participate because of the environment.

Viktor: That is not a terminology problem.

PR: No, that's not the case, language is part of it.

Lars Eggert (from webex): +1 to pete, heard the same things. also heard from
men who find the environment too harsh to justify their involvement

Viktor: agreed, there are those other issues, but again the list of terminology
in this dispatch does not address women.

PR: Sounds like you are speaking without experience of talking to these
peoplee. I want to make sure people do not say certain things do not exist
because they have no experience of it.

Viktor: I would be all over supporting about making the IETF more welcoming for
women, as opposed to technical terms. That issue is a real issue.

Colin Perkins (Webex): I've also heard these things many times – the style of
communication matters

Rich: "People who might be offended are not in the room" I was not commenting
on why they might or might not participate. One of the possible reasons for
which people are driven away is the language. The industry is moving this way.
If you look at the github page, every word endorsed is considered as
problematic by multiple organizations.

Andrew: The RFC could go beyond terminology, and talk about inclusivity more
broadly. On the list of forbidden words to be avoided, it needs to be
approached with care, maybe learning from people who have had previous
experience. Focusing on the positivie might be more productive.

Kyle Rose (Webex): We should do something about the bullying, mocking,
harassment, and exclusion. The terminology is window dressing.

Lars Eggert (Webex): increasing gender balance is one axis in which we want to
become more inclusive. there are other axes for whom terminology matters more.

Bron: What are our success criteria for this work? One of their main objections
of the authors of the terminology draft (draft-knodel) is that it does not cite
references and does not point to scholarly research. Don't think we want to try
to base ourselves on references, I would prefer to do it on sound principles.
We need to have our eye on producing high quality technical content and the
reason for including additional people and for more diversity is to do better
at our goal. Inclusivity as a way to producing that high quality docs.

PR: Appreciate that. What are we going to do, do we count this as important
immediate issue or minor thing that would be good to do anyway? What is the
outcome that we want?

Bron: I think we should publish a welcoming document, informational RFC saying
we want to use inclusive language, we want our environment to be welcoming.
Different (long-term) mailing list than ietf ml to discuss terms. Needs to be
ruled and built in a way that does not devolve into people fighting at each
other. Document based on principles not on references. Less inclined to put a
list of words than at the beginning of the meeting because of the
incompleteness problem. Having a place where to accumulate the things we know
about is a good idea.

FP: See many +1 in the chat. Anybody objecting to Bron's proposal, principle's
document?

John: Such a document would be a good idea, probably. Based on: is that
document expected to reflect IETF consensus, the clear opinion of an individual
or two, or something else? If we dispatch it to IETF consensus document, that
means taking us down another rat hole of discussions that will distract people
from doing IETF technical work. I favor the idea in principle but have great
concerns about how to get there.

Viktor: I would support the principle document, especially if it leaves the
terminology list entirely out. Then we are talking about communicating clearly
and sensively, not feel like there is a language police standing behind my back.

PR: Do you object to having a list of words with a discussion about why or
possible alternatives, or is the list right out?

Viktor: Don't see the possibility of consensus on such a list. If the list
sticks entirely to positive "here are the good terms", we may be able to
converge on some subset.

Robert: Supporting Bron's suggestion. Positive document is the way forward. I
support not putting a curated list of terms, that would be a bad idea. If you
have such a list, that list should be able to change over time. I think it's
good to have such a list (github with a link) outside of the document. Not say
the words are "problematic" but rather "potentially problematic". More about
advice and alternatives. Agree with Bron that we don't need to include
references as why we are doing this.

Keith: Like Bron's proposal, especially about making it welcoming. Any
discussion about words and terminology belongs in a separate place. We probably
need that. We don't have the strong objectors on this call, I suspect we will
get pushback if we don't have a place to put examples of terminology. Outcome
of this meeting proposal: the right answer is create a mailing list. We do not
have a proposal at the moment to say "let's make this an RFC".

PR: If we do propose a document, let's say AD sponsored, who gets to chose who
is the editor and what that document is going to be looking at, wouldn't be
easier to do a short lived wg?

Keith: About WG, there is a presumption that the wg is going to produce an
output. That might be a little bit unconstructive. There is problem with both
approaches. I feel like we need some concrete output of this meeting so we
don't loop forever.

Rich: Support document, good examples (column B from terminology in github)
needs to be there. If something new comes along how do we update the RFC?

FP: From the chat "can't Bron's document be the starting point to the
principle's document". From previous meeting, Bron's document was the one with
the most support.

PR: Are people in this room inclined to take Bron's document as the input
document for something AD sponsored as the principle document and carve it down
to a consensus document, or are there people that think that this is not a good
idea?

Viktor: not much experience on IETF process. Neither sounds objectionable.

Rich: Concern was raised that "wg is designed to produce an output", but if AD
sponsored, that's the same thing. What's the difference?

PR: WG gets push to get document out, while the AD sponsored might not have
that kind of bias. If we set up a mailing list it would not be as heavily
managed as if it was a WG.

Bron: Yes, I would be ok with being volunteered to author this. Would like to
have more authors, from a variety of viewpoints, certainly the authors of all
three docs. Otherwise we are not going to find conensus.

Andrew: if other help is needed I'd be happy to help. I'm conscious that 50% of
the people on this call commented on the mic, it would be interesting to hear
from the rest of the people.

Robert: not opposed to go the AD sponsored route. I like the quick spin up WG +
long term mailing list. Easier to find and know where the discussion is
happeninh. Does a wg have to produce an output? This could be part of the
charter, to say the charter is to investigate this, but a valid outcome would
be "there should be no document".

Colin Perkins: good points in Bron's document. Mallory and Niel's document
recognizes that we have a broader issue of inclusivity in the IETF. Building on
some of the other documents, I am concerned we would miss this broader issue. I
don't think Bron's document would be the right starting point.

Viktor: It is specifically in inclusivity that I find draft-knodel exclusionary
and offensive. And would not like to see it progress.

Mirja: having a discussion about this is a first step about inclusivity,
proposal for recommendations is another step. Welcoming document is not going
to hurt, but that's not going to change anything.

Adrian Farrel: +1 to Mirja. Dispatching the topic or the document? Dispatch of
document seems to require selecting a document which prejudges what a WG might
do.

PR: Particularly the topic. I heard that people were agreeing that dispatching
Bron's document was making people confortable.

Adrian: Inclusivity WG suggested in Webex and would be an example of
dispatching the topic not the document.

PR: WG for that is one choice, IAB program another choice.

FP: Different proposal if we go for inclusivity wg, that would not be a quick
spin up wg.

Bron: Agree with Mirja. We definitely would need to get Mallory and Niels on
board. We want to get consensus.

Mirja: general topic of inclusivity is very broad, that's why we're not making
progress. Not sure about having more discussion in a wg or mailing list will
move us forward because it's very different angles which need different
measures. I'm a little bit disappointed because as IESG member we thought this
would be small angle easy to address. Disappointed to see so much controversial
discussion. Have a wg include everything would not be more productive.

John: Part of what I'm concerned about here is that we go down a path of
looking at terminology in a way which itself becomes exclusionary. It's a
broader issue but we need to be very careful. I support Mirja's original
comment but not certain about her second one.

Keith: Don't think we should recommend inclusivity WG right now. By starting
with this language topic, it might have created more controversy than
necessary, because there is more ways in which IETF is not inclusive. Focusing
on that topic might have caused more heat. We have to adress the language
topic. I like picking Bron's doc as starting point, moving forward with that, I
could be persuaded either WG or AD sponsored + ml.

Andrew: inclusiveness wg - should be on the basis that this doc should be the
first output from it. Learning from last document that was pushed out by IESG,
it should be a requirement that the document should be issued well in advance
before the next IETF meeting.

PR: Hearing that people think that we might get a principle document done,
something bigger on inclusivity is a good thing but maybe not ready to dispatch
out to. Haven't heard objections on program on inclusivity, but objections on
something to dispatch right now.

John: The issue with a WG and inclusivity is that our primary target should be
is how we can change vocabulary and how people behave rather than on producing
a document.

Mirja: Goal is changing behavior, but that this is not something we can achieve
by writing an RFC. Recommending terminology and raising awareness are steps.

PR: Objection to going forward with a document about the language issue?

Mirja: If we have a document, we clearly need to state the problem.

Bron: Looking for a path that persuades people rather than a path telling
people what to do. Forcing to change is what people in the ml were worried
about.

Keith: rough consensus is on a decision, not on a motivation. It's better if we
don't have to go to the reason, because we are never going to get consensus. I
agree attitudes have to change, but we can't tell people what attitude to have.

Mirja: Agree, hard to get agreement on problem, but in this case the only way
to get people to change is to agree on the problem, accepting the problem. I
don't think that an RFC is the right instrument, but if you do, then
documenting the problem seem like the way to go.

Keith: Emphatically disagree.

PR: describing that we want to be inclusive implies the inverse, that by not
thinking about this terminology you are being exclusive.

Viktor: there is a difference between saying we want inclusivity and saying
"you are being exclusive in these particular questionable ways".

PR: pointing fingers is always problematic. We want to avoid characterizing
motivation and going with the assumption that people are trying to do the right
thing.

Viktor: Bron's document is good and the countrapositive isn't. I am comfortable
with the "we want to do better".

Bron: Are you (Mirja) asking this document to say "IETF is bad and exclusionary
and we have been using bad language?" That is what a lot of people object to.

PR: Framing it as bad is already the leap. Framing it as "language we've used
has been exclusionary / not as inclusive as we could have been", those I have a
hard time distringuishing.

PR: Summary: principles document out, mailing list / WG + ml / AD sponsored. We
want to address the bigger issue in some way.

*[PR]: Pete Resnick
*[FP]: Francesca Palombini

## Webex Chat Log

You13:02
Minutes and Bluesheet:
https://codimd.ietf.org/notes-ietf-interim-2020-gendispatch-03-gendispatch?both
You13:03 Minutes and Bluesheet:
https://codimd.ietf.org/notes-ietf-interim-2020-gendispatch-03-gendispatch?both
Bron Gondwana13:07 +q You13:10 (Please keep comments to the jabber room:
gendispatch@jabber.ietf.org and keep the webex chat for queue management) Keith
Moore13:11 +q Bron Gondwana13:12 +q JcK13:12 +q
Andrew.Campling@419.Consulting13:12 +q Viktor Dukhovni13:13 I fear Wikipedia
editor wars... Keith Moore13:14 @viktor: I wouldn't want it to be editable by
everyone. Viktor Dukhovni13:16 +1 JcK13:16 +q Bron Gondwana13:17 +q Pete
Resnick13:17 To whom Viktor? Viktor Dukhovni13:18 John Klensin Pete
Resnick13:18 ack Keith Moore13:18 @andrew: personally agree github is the wrong
place to host permanently Bron Gondwana13:18 which leads us back to an IANA
registry managed by some process... Keith Moore13:18 to me it doesn't seem like
a great fit for IANA Viktor Dukhovni13:19 +q Bron Gondwana13:21 +q Keith
Moore13:21 +q Bron Gondwana13:22 -q Rich Salz13:23 "Declare victory and get
out" was from the Vietnam War startup. You13:23
https://github.com/ietf/terminology Rich Salz13:25 q+ Barry Leiba13:26 q+ Keith
Moore13:26 q+ Bron Gondwana13:26 q+ Viktor Dukhovni13:26 +q Rich Salz13:26 q+
Keith Moore13:29 Perhaps if we're going to publish as an RFC, we could at least
wait a year or two until it stabilizes. Bron Gondwana13:30 Authors MAY
substitute a term from this list: Bron Gondwana13:30 +q You13:31 (Reminder: if
you put comments in the jabber we're going to be able to retrieve them later
on, so please do comment in the jabber if you can) Keith Moore13:31 It would
take me longer than this meeting to get set up to use jabber. Pete Resnick13:31
:) Rich Salz13:32 +1 to Bron You13:32 No worries :) speaking at the mic is
recorded too. JcK13:33 +q Andrew.Campling@419.Consulting13:33 +q Bron
Gondwana13:34 +q Keith Moore13:34 +q Viktor Dukhovni13:38 Agreed with Andrew
and John. Bron Gondwana13:38 +100 for dispatching to the IAB and making it
someone else's problem :p Keith Moore13:39 :) JcK13:42 +q
Andrew.Campling@419.Consulting13:46 +q Rich Salz13:47 +q Bron Gondwana13:47 +q
Keith Moore13:48 agree at least to the extent that we need to be seen as doing
_something_. hopefully something minimal JcK13:48 +q Viktor Dukhovni13:49 +q
Keith Moore13:49 I wouldn't describe it as having offended people "take on the
responsibility", but I do think that having people who aren't in the position
of being offended act as proxies for those who supposedly are offended, is a
recipe for disaster. Rich Salz13:51 I understand, but for the safety of those
people, it might be the best we can generally do. "Blame the victim" is far too
common, even in this topic as we've seen. Kyle Rose13:52 Bron, what you just
said should be added verbatim to the document. Well said. Keith Moore13:52 we
want to figure out how to make it easier / more attractive for more diverse
people to show up. we really need for IETF standards to have input from a wider
variety of people, from a wider variety of cultures and conditions. Rich
Salz13:52 ++Keith Andrew.Campling@419.Consulting13:55 +q Rich Salz13:56 +q
Keith Moore13:56 It should certainly be okay, in a WG, for someone who believes
language is exclusionary or offensive, to send a private comment to authors
and/or the chairs. Robert Wilton13:58 +q Bron Gondwana13:58 +q Viktor
Dukhovni13:58 +q Keith Moore14:00 +q Keith Moore14:01 agree with having "why"
Lars Eggert14:01 fully agree with rob Rich Salz14:02 ooh, that's hard to think
about bron; thanks. Keith Moore14:02 if you want to be inclusive, be prepared
to listen to contributions that don't fit your preconceived framing of the
question :) Keith Moore14:03 -q Rich Salz14:05 +q
Andrew.Campling@419.Consulting14:05 q+ Juliana Guerra14:05 I agree with Rich's
last comment. There are a lot of barriers for people potentially offended by
this kind of exclusionary language to give any feedback on any IETF document.
And just a few people is now participating on the discussion. Lars Eggert14:07
+1 to pete, heard the same things. also heard from men who find the environment
too harsh to justify their involvement Bron Gondwana14:08 +q Keith Moore14:08
pete, could you cite a concrete example? Colin Perkins14:08 I've also heard
these things many times – the style of communication matters Kyle Rose14:09 We
should do something about the bullying, mocking, harassment, and exclusion. The
terminology is window dressing. Lars Eggert14:10 increasing gender balance is
one axis in which we want to become more inclusive. there are other axes for
whom terminology matters more. Pete Resnick14:11 @Keith, I can, probably
offline. Kyle Rose14:13 This whole discussion feels like a "white man's burden"
discussion. It seems we are projecting left-wing impressions of fragility on
other cultures without any actual evidence that this is a problem. On the
contrary, sexism is absolutely a problem in the IETF, yet we do nothing about
that. Kyle Rose14:13 To the point of the middle-aged white men, I think that is
easily explained by selection bias. Middle-aged white men were teenage nerds
who spent lots of time in front of their computers in the 80's. Keith
Moore14:14 @Kyle: not sure about "we" but I do think the "left-wing
impressions" are part of the problem (even though I don't care where on the
multidimensional political spectrum they come from) Robert Wilton14:14 +q
Viktor Dukhovni14:15 +1 for Bron's current comments on sound principles! Keith
Moore14:15 agree with staying focused on the goal of technical documents
Andrew.Campling@419.Consulting14:16 +1 to the point on references being made by
Bron Kyle Rose14:17 Anyway, I'm not saying this is not a problem at all, only
that it is a minor part of the problem and we are spending way too much time on
it. Let's move Bron's draft to a place where we can refine it and publish it,
and then maybe deal with some of the other problems that AFAICT are more of a
problem for inclusivity. Happy to provide specific examples privately. (I will
not call out people in public.) JcK14:18 +1 to looking closely at a welcoming
document (or updates to the current ones) Keith Moore14:18 I like Bron's
proposal. Andrew.Campling@419.Consulting14:19 +1 for a welcoming RFC Keith
Moore14:20 what kind of responses are you looking for? Keith Moore14:21 +q Rich
Salz14:25 +q Kyle Rose14:27 If we do that, can we exclude a few specific trolls
from said mailing list? Keith Moore14:27 @Kyle :) Kyle Rose14:27 I'm only
slightly kidding Bron Gondwana14:27 Here comes the exclusion :p Juliana
Guerra14:27 What do you mean with trolls? Kyle Rose14:27 Like I said, I will
not call out people in public, but there were a few people on the original
thread who were simply trying to ignite a flame war. That is not productive.
Kyle Rose14:28 Happy to provide examples privately. Viktor Dukhovni14:28 Isn't
Bron's document looking like a plausible consensus starting point. Pete
Resnick14:29 Let's not impugn characters, even in the chat room. Pete
Resnick14:29 (@Kyle) Kyle Rose14:29 Exactly why I will not name people in
public. Juliana Guerra14:29 @Kyle I think it's important to better point what
you mean with "trolls" and "ignite a flame war", aren't these people part of
IETF? Are you referring a hostile enviroment? Kyle Rose14:30 @Juliana Yes, I
believe the people I'm referring to were creating a hostile environment. Which
is far more of a problem than the terminology issue.
Andrew.Campling@419.Consulting14:30 +q Keith Moore14:30 I would certainly
accept Bron as editor of a welcoming document, and it would probably crib some
text from his existing document. Kyle Rose14:31 +1 to using Bron's document as
a starting point Bron Gondwana14:33 +q Andrew.Campling@419.Consulting14:33 +1
to starting with Bron's document, building from there Robert Wilton14:33 +q
Colin Perkins14:34 +q Keith Moore14:34 happy to help with the document Keith
Moore14:34 (but I suspect you're the editor in chief) Keith Moore14:35 @bron
Keith Moore14:37 @Robert: good point. WGs are hard enough to see, IMO, mailing
lists even moreso. tale14:38 I haven't commented at the mic because largely
other people have made any points I've wanted to make, and I'm just one more
white guy. I have been happy to see the course of the discussion and the
respect with which it has been mutually held. Viktor Dukhovni14:39 +q
Andrew.Campling@419.Consulting14:39 Draft Knodel was, to me, far too US-centric
Mirja Kühlewind14:39 +q Keith Moore14:40 +1 to viktor's comment. I'm all for
broader inclusivity in IETF, but that document is not a good starting point for
that. The discussion in manycouches is a lot more relevant to that. Bron
Gondwana14:40 +q Keith Moore14:42 maybe IETF needs an inclusivity WG, not
specific at all to language? Juliana Guerra14:42 That would be very good! Kyle
Rose14:42 I would be on board with that, as long as it doesn't end up like
hrpc. It would need broad participation. Mirja Kühlewind14:42 +1 Rich Salz14:43
Last meeting I suggested an IAB program for Diversity, Inclusion, and Growth.
Andrew.Campling@419.Consulting14:43 +1 to an inclusivity WG, with inclusive
terminology be a possible topic for a first informational RFC Keith Moore14:43
so IMO it would need to address things like meeting fees, learning curve for
newcomers (especially those not accustomed to consensus based decision making),
decorum Bron Gondwana14:43 the group yes, the first document no - we can't
address the world in one document! Keith Moore14:44 one of my beefs about the
nodel document is that it discusses inclusivity in very narrow and highly
dubious terms. Mirja Kühlewind14:44 I mean +q actually not +1 Keith Moore14:45
yeah I don't think the output of this meeting should be to recommend an
inclusivity WG and go home. JcK14:45 +q Keith Moore14:45 @bron: good luck :)
Juliana Guerra14:46 I prefer an Inclusivity WG than a set of principles and end
the discussion here Keith Moore14:46 +q Viktor Dukhovni14:47 I asm sceptical
about progress if all the authors are stirring the pot. Mind you if I wanted to
see it sink that might a good way to do it ... :-)
Andrew.Campling@419.Consulting14:47 +q JcK14:52 +q Kyle Rose14:52 I'm not sure
draft-knodel has anything of value that isn't covered better by the other two
documents. If my goal is to achieve rough consensus on something, I'd want to
keep those two authors far away from responsibility for whatever document we
advance. Keith Moore14:52 I would rather NOT make Bron's document an output of
an inclusivity WG. I feel like that would be a huge misstep. Mirja
Kühlewind14:53 +q Bron Gondwana14:53 +q Keith Moore14:54 IMO the inclusivity WG
should start out addressing the broad topic, not narrow on one specific topic,
even to start. Juliana Guerra14:54 Agree Keith Moore14:55 +q
Andrew.Campling@419.Consulting14:55 Position a terminology informational RFC as
the first in what might be a series of documents on inclusiveness Keith
Moore14:55 @andrew: please no Mirja Kühlewind14:57 +q
Andrew.Campling@419.Consulting14:57 +1 to not needing to agree on motivation
Keith Moore14:58 +q Bron Gondwana14:59 +q Juliana Guerra15:00 I don't see the
problem of recognizing how one have been exclusive and propose one step to be
less exclusionary Keith Moore15:01 @Juliana: sometimes there's disagreement
about whether a particular practice is exclusionary. also, "exclusionary" might
be an exaggeration, even if we could do better. it's a kind of accusation,
which makes people defensive. Juliana Guerra15:01 But there's IETF consensus on
the need to promote inclussion Andrew.Campling@419.Consulting15:01 @Bron IMHO
Better to focus on the positive, that the IETF aspires to be more diverse Keith
Moore15:01 but not IETF consensus on what inclusion looks like Kyle Rose15:02
Let's keep value judgments out of it. That's what triggered a lot of the
push-back on draft-knodel. Keith Moore15:02 Kyle +1 Juliana Guerra15:02 Isn't
that recognizing that it's been exclusionary? The issue for me is to recognize
and try to understand how, to make beeter decisions in the future Bron
Gondwana15:02 If we make Mirja and Juliana feel that it hasn't addressed their
concerns then it hasn't succeeded Bron Gondwana15:03 Juliana - the question is
whether we're using positive encouragement or whether we're confessing sins
Keith Moore15:03 @juliana, it's easy to find examples in which IETF is
exclusionary, but language (while it could be better) seems like an
infinitesimal fraction of that Keith Moore15:03 IMO accusations are not
constructive Bron Gondwana15:03 If we need the IETF to confess sins that will
be a hard sell Juliana Guerra15:04 It's not about confessing sins, it's about
understanding Kyle Rose15:04 There is no evidence that terminology has actually
excluded anyone. I could get behind "potentially exclusionary", but let's leave
the value judgments and questionable sociological claptrap out of whatever
document we produce. If there's anything like section 2 of draft-knodel in the
document we advance, it will produce another huge flame war and get precisely
nowhere Keith Moore15:04 from someone who grew up in a fundamentalist world,
confessing sins is not always a good thing. it is often a way of avoiding
change rather than accepting it. Andrew.Campling@419.Consulting15:04 Pete and
Francesca Thank you both for navigating this difficult path Rich Salz15:05 yes,
thanks! Kyle Rose15:05 Yes, thank you, Pete, Francesca, and everyone else who
contributed. This was a really good, productive, respectful discussion. Bron
Gondwana15:05 Thanks everyone. I wish we'd got to this bit earlier, because
it's the core of the issue! Keith Moore15:05 thanks to everyon!