Minutes interim-2020-gendispatch-01: Tue 20:00
minutes-interim-2020-gendispatch-01-202009012000-02

# Gendispatch Interim
Tuesday 2020-09-01 20:00 UTC
Chairs: Francesca Palombini, Pete Resnick

Recordings: https://youtu.be/VRfvPWeI1xs

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

Minute takers: Francesca Palombini, Rob Wilton

## Bluesheet
(39 participants)

1. Francesca Palombini, Ericsson
2. Pete Resnick, Episteme
3. Keith Moore, Network Heretics
4. Mallory Knodel, Center for Democracy & Technology
5. Adam Roach, Independent
6. Mirja Kühlewind, Ericsson
7. Robert Sparks, AMS
8. Brian Carpenter, U of Auckland
9. Colin Perkins, University of Glasgow
10. Niels ten Oever, Texas A&M University - University of Amsterdam
11. Jay Daley, IETF Administration LLC
12. Bron Gondwana, Fastmail
13. Alissa Cooper, Cisco
14. John Border, Hughes
15. Joel Halpern, Ericsson.
16. Rich Salz, Akamai Technologies
17. Russ Housley, Vigil Security LLC
18. John Levine, Standcore
19. Melinda Shore, Fastly
20. Xavier de Foy, Interdigital
21. Alvaro Retana, Futurewei Technologies
22. Nick Doty, UC Berkeley
23. Eliot Lear, Cisco Systems
24. Andrew Campling, 419 Consulting
25. Jim Fenton, Altmode Networks
26. Eric Rescorla, Mozilla
27. Nicolas Williams
28. Bob Hinden, Check Point Software
29. Martin Duke, F5 Networks
30. Shivan Sahib, Salesforce
31. Barbara Stark, AT&T
32. Michael Richardson, Sandelman Software Works
33. Rob Wilton, Cisco
34. Viktor Dukhovni
35. Kyle Rose, Akamai

## Agenda & Minutes

Agenda bashing - no comments

- Chair intro (5 minutes)

        * 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)

Eliot Lear: to the chairs: what are our options, if we are not able to discuss
content? PR: we can discuss content as long as the dispatch question is in
mind. Alissa Cooper: Please can you clarify the relationship between this
meeting and next? PR: discussion for this meeting will be summarized to the
list and fed into next week (for whoever couldn't make it, or if additional
issues come up).

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

 MCR: Can we file an errata against existing RFCs for offensive terms?
 Keith: could be an option, another option is "moving forward we are not going
 to use these terms". Don't want the rippling effect of revisions. Bron
 Gondwana: changing terminology is easy in documents, but a lot is in code as
 well. Andrew Campling: Search and replace might be problematic.  What is your
 view on quoting offensive terms in documents? Keith: You need a good reason to
 change existing terminology. Wouldn't make a broad recommendation about that. 
 Subject matter experts are best placed to choose the appropriate terminology.
 PR: Comments should be aimed as dispatching rather than how specific documents
 should be fixed.

        * Summary from IETF108:
                - there is difference of opinion between the problem this draft
                wants to solve and the draft itself (we are trying to dispatch
                the problem as well as the draft) - there were different
                opinions between the problem this draft wants to solve and the
                draft itself (we are trying to dispatch the problem as well as
                the draft) - there was support on the statement that IETF
                should address the problem this draft brings forward - sense of
                the room that draft-knodel-terminology is not a good starting
                point - there needs to be more discussion on content to
                understand what would be a good starting point - there exist
                several options for the discussion on content to take place.
                The sense of the room was that discussion on ietf@ietf mailing
                list was not productive. Options:
                        * Consensus on need for a dedicated mailing list +
                        virtual meetings (/interims) (note: some content
                        discussion was started on gendispatch, in the meantime)
                        * AD sponsored (which would remove the overhead of
                        creating a new WG)
                                - where to have the f2f discussion?
                        * dispatch to a new WG, which would give a clearer
                        place to build consensus and have discussion * dispatch
                        to BOF for discussion * IAB program

        * Brian Carpenter summary of outputs [4] (not complete, does not list
        IAB program, BOF, ...):
                1. Recommend that it be dropped from IETF consideration...
                1.1. ...and referred to the Independent stream
                1.2. ...and referred to the RFC Editor
                1.3. ...and forgotten
                2. Recommend that a WG on this topic be formed...
                2.1. ...and asked to use the draft as a starting point
                2.1. ...and asked to start a completely new draft
                3. Recommend that a sponsoring AD be found...
                3.1. ...and that the draft be used as a starting point
                3.2. ...and that the AD solicits a completely new draft
                4. Recommend that the issue be handled solely by the IESG
                5. Recommend that the issue be handled solely by the RFC Editor

[1] https://www.ietf.org/proceedings/108/minutes/minutes-108-gendispatch-01
[2] https://www.ietf.org/jabber/logs/gendispatch/2020-07-30.html
[3]
https://mailarchive.ietf.org/arch/msg/gendispatch/zsIVefDQLzKQ2WF4KuKyPm1_mFI/
[4]
https://mailarchive.ietf.org/arch/msg/gendispatch/ne7FQEBQeHmbz_7y62wpJuAR9NA/

### Discussion

Jim Fenton: Concerned about how this discussion is being seen from the outside
as an official IETF position.  Mallory draft has been cited.  Also looking at
the github repo and it looks like an official IETF position. PR: Yes this is a
problem, please try and be careful.

Viktor Dukhovni: re:dispatch 1. we don't have to ban language that is on the
process of going away naturally. Not convinced that any of these drafts need to
progress. 2. In some way IETF is quite exclusionary, not in the ways that these
drafs are aiming to address, but primarily on the energy and time that one
needs to be able to afford to engage (but few can afford), also because
participants are funded by major market participants. In conclusion: these
drafts should not go any further.

John Levine: Viktor said what I wanted to say. RFCEd would not be a good
dispatch, this should not be their problem.  Style guide would be fine.
Decision still should be kept in the WG (editors, chairs etc). Of the 3 drafts,
Bron's is the best to move forward.  But question whether we should spin up
process for this work.

Dan Harkins: Second what Jim said. Re:dispatching - agree with Viktor, but so
many people support it so it might not be possible. BOF and WG may not work
well.  Probably best option AD sponsored draft. Best of the 3 probably Bron's.
Section 3.2 especially is missing from the other 2.

Bron Gondwana: Part of this document isn't for the IETF, but is to be
referenced by the outside world. Need to be careful that we don't do something
that doesn't help IETF's mission, and avoid fighting the world's battles.

Michael Richardson: BoF would be a real problem. Keith and Bron produce an AD
sponsored document.

Mallory Knodel: Without the original draft, the other 2 don't make a lot of
sense. In 2018 there were a lot of people questioning if the harm was
legitimate, this draft came from those questions. It summarizes the discussion.
Bron's reads as the most reactionary, but alone it does not make sense. I don't
think it fits as BCP. The reason for including the statement that the
discussion created harm is important, which is why it's included. I am happy to
make changes, I think it needs to advance.

Nico Williams: Re:dispatch - I stopped using this language long ago based on
the precautionary principle. We could publish these (any particular draft or
all of them) as Informational initially based also on the precautionary
principle, then perhaps progress to BCP. The effect has been had whether we
even publish one, let alone three or five. Given that the effect has been had,
I don't think there is any urgency to see any publication. Informational
followed by BCP is good. Could go via ISE, otherwise don't know where (BoF, WG)
they should really go. Agree that RPC (RFC Production Center) cannot do it. 
RSE can do it provided there is a process for it. Regarding exclusionary
policies of IETF - ISOC used to have a program for inclusivity, but apparently
it has ended. An inclusivity program, possibly sponsoring attendance by
participants with limited resources, is a very productive thing that we could
be doing. Better to focus on inclusion where we can be productive than
exclusionary language that we won't be using any more anyway and where there is
not enough certainty as to whether it actually excludes.

Barbara Stark: I would like to see an RFC published that creates and mantain a
list of terms to be cautious about using.  Language changes over time, people
around the world may not be aware about language that is no longer acceptable,
hence good to have references. Conclusion: I support having something
published, but concerned about going the AD route.

Keith Moore: to Viktor's point: emphatically disagree. In IETF we try to find
rough agreement between people with different perspective. We are actually more
inclusive than other groups. I would not want to publish any of the docs in the
current form. A document needs to be produced out of this. Skeptical about AD
sponsored. Needs to have more visibility, even if more difficult.

Niels ten Oever: IETF does not look like the rest of the world.  Different
meeting styles, text tools.  IETF has not diversified, perhaps we should take
the norms into account, not just of the people who are already here, but also
people who should be here.  Our infrastructure has a great impact on society,
but it is not just technical. Perhaps we could find an outside group of people
who could advise the AD on how to move forward.

Bob Hinden: These documents are a bit like architecture documents that are hard
to get consensus on and get published.  Like what has been put on github, and
think that we could get consensus around.  Having a document that points to an
external list (e.g., github) would be just fine.  Don't need a WG to achieve
this.  AD sponsored would be fine.

Martin Duke: Concur with Barbara. Not strong opinion on AD sponsored or WG. I
like parts of all three drafts but think it's very important to have at least a
few actionable terms that the industry is converging on (like the -knodel
draft). Do authors have fundamental disagreement or could they work together to
merge these 3 drafts? Or are there differences that would make that difficult?
PR: If the document was dispatched to a WG then the WG chairs might appoint an
editor. Martin Duke: maybe there is some common ground. Keith (from chat): Not
sure, to discuss offline.

Eliot Lear: Thanks all three authors.  If we dispatch to AD and then need a
long last call debate then that will not go well. Hence, maybe better to have a
WG with a particular modality: Perhaps dispatch to a WG that is focused on just
a single draft, doesn't meet in person, but does have interims. Yes, I have a
preference for Bron's draft as a starting point.  And I see value in finding a
way to also keep Mallory's and Niels' work alive.  However, I don't quite know
what venue should manage its development, because I share Barbara's concerns
that we may not have enough of the right people in the room to provide for
proper review.

Viktor Dukhovni: Just wanted to clarify. IETF is by far the most inclusive
group in terms of the ability to participate. But the ability to participate is
no guarantee that one's views not end up in the rough. Though the IETF is not
exclusionary, it is not possible to make it *representative*. Best outcome is
acknowledge that the language is changing naturally, without any supervisory
input, not publish any of these drafts, and move on. Example of
"man-in-the-middle" from Knodel draft: the term is widely used in books (e.g.
Applied Cryptography), and widely understood. Most of these things are fishing
for problems where there is none.

Andrew Campling: Agree on Barbara's comment about cautious. Maybe this is a
relatively small part on the issue of inclusion. Something needs to be
published. Bron's document seems like the right starting point, to build from.
Should not be a US centric document. It could be a serie of documents on
inclusion.

Brian Carpenter: re:dispatch - review teams in IETF. Don't remember a single
case where reviewer has said "you might want to change term X to term Y". We
need to make sure that review teams are aware. PR: early vs late review issue.
Do you think it could be a problem if late review is where these comments could
happen? Brian: it's possible. Early review is even better, but we don't need a
early review team.

Nico Williams: Second what Brian just said. Don't need early review. We saw a
lot of debate on this. Publishing as informational seems like the right thing
to do. It causes friction to ask for prior restraint. I am not objecting to
publication of any of the three drafts, as informational, especially if
problematic language is softened. Waiting a few weeks might actually help.
About expertise: yes we do lack expertise on social issues, in general, as a
group.

Mallory Knodel: I agree with publishing other drafts beside ours. But I find
Keith and Bron's draft to be odd in the vacuum. If we want to pare it down, I'm
fine. It's not outsider that are coming in. There is expertise within the
community.

Nick Doty: I think it is important that we talk about non-goals, in terms of
inclusion or participation. Re:dispatch - update to the style guide? PR: BCP
that says you should consult the style guide, would this be acceptable? Nico
Williams: We can use informative language, I am a lot more comfortable with
that.

Colin Perkins: Wonder what the goal of this work would be from this group.
Raccomendation on language use? Or longer term problem, and that we are trying
to be more inclusive? One of the things I like from Mallory and Niel's draft is
that we need to pay attention to ways we do our work.

Rich Salz: Concerned about the cost of us doing nothing, in terms of
perception. The larger problem of inclusivity and growth is a real problem for
IETF. Re:dispatch - IAB to start an inclusivity and diversity program and this
draft go there.

Viktor Dukhovni: About inclusivity - one has to be careful about whom
"inclusivity" excludes. We don't want to exclude IETF participants who would
chafe at policing of words.

Joel Halpern: I hope we can get to a point where we get "people should avoid
these terms", and not policing. (...) No an IAB program should not do this.
Maybe a serie of BoFs? To craft the initial document in a community fashion.
PR: Eliot mentioned quick spin up-spin down, loosely chartered, would that be
acceptable instead of BoFs? Joel: sometime they work, sometime they don't.

Bron Gondwana: RFC3539 mission statement for IETF, does not specify diversity.
Any effort should be added to the mission statement.

Barbara Stark: Joel said much of what I was thinking. To me one of the primary
reason to avoid words like these is that everybody knows (that they are
exclusive). List of these words would be helpful for people not unkwnowingly
using them.

PR: Conclusion (to check with Alissa and Francesca + minutes): we need to do
something. Good support for not AD sponsored, more BoF or short-lived WG. About
documents, pieces missing and things people objective to all of the 3
documents. Bron: we might not want to decide at the end of this meeting, but
wait for second meeting. PR: Yes, we will summarize the discussion today and
feed it as input to second meeting. Second meeting will be summarized and
posted to the mailing list. Eliot: only thing to add to summary: important to
capture the comment Colin made about scope. Francesca: this could be part of
the charter discussion. Mallory: Don't think there is clarity in what needs to
be changed in the document. Chairs please put the github in the agenda. Robert
Sparks: There was support for AD sponsored. Alissa Cooper: difference about AD
sponsored and WG, it's about the difference in the way the community can
participate on. Do people want an RFC or not? What other activity do people
want? PR: Not only consensus document, BCP or anything else. Francesca: Support
for Rich's idea of IAB program in the jabber.

*[PR]:Pete Resnick