Subject: [Gendispatch] Diversity and Inclusiveness in the IETF

From: Fernando Gont <[email-masked]>
Date: Mon, 22 Feb 2021 21:07:19 -0300

Folks,

We have submitted a new I-D, entitled "Diversity and Inclusiveness in 
the IETF".

The I-D is available at: 
https://www.ietf.org/archive/id/draft-gont-diversity-analysis-00.txt

We expect that our document be discussed in the gendispatch wg 
(https://datatracker.ietf.org/wg/gendispatch/about/). But given the 
breadth of the topic and possible views, we'll be glad to discuss it
where necessary/applicable/desired.

As explicitly noted in our I-D, we're probably only scratching the 
surface here -- but we believe that our document is probably a good 
start to discuss many aspects of diversity that deserve discussion.

Thanks!

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

---

From: Dominique Lazanski <[email-masked]>
Date: Tue, 23 Feb 2021 09:18:16 +0100

I would support Bron’s experience and also say that there are several other barriers to entry that I’ve found. One is different approaches to topics than the mainstream IETF approach held by most IETF attendees. I am thinking about privacy/encryption, for example. But the other big barrier to entry is the draft upload tools. For a new person attending for the first time the tools are a relic of 1990 of thereabouts and can be confusing and difficult.

In any case, I shall join the gendispatch group to discuss further!

Dominique

> On 23 Feb 2021, at 05:19, Bron Gondwana <[email-masked]> wrote:
> 
> Thanks Fernando,
> 
> I would add to this document something about inertia, backwards compatibility and existing dysfunction.
> 
> Many ideas are shut down because they aren't in the right place, or don't fit comfortably into the existing corpus of IETF documents.
> 
> When we brought JMAP to the IETF it was after a long process of socialisation, and still there was significant work in the first couple of meetings just to convince people that "this is worth doing, the existing work the IETF has done in this neighborhood is not sufficient".
> 
> JMAP also had an authentication scheme in it originally.  It was a good authentication scheme, but applications don't do authentication schemes, that's the bailiwick of OAUTH, where ideas go to die (in my experience, that working group has been dysfunctional for my entire time at IETF - exhibit 'A' being the "Milestones" section of the about page, which lists 6 items all due in 2017)
> 
> So we just removed all mention of authentication method and handwaved "the connection will be authenticated", because we wanted to publish something during the decade with years starting '201'.
> 
> ... all that to say.  One of the biggest barriers to entry in the IETF is stumbling across an area in which no work is able to progress due to entrenched issues within that area.
> 
> And I'm not arguing for "no barriers to entry", because there needs to be a sanity check that we're actually producing high quality specifications, and that our specifications are compatible with each other so the entirety of the IETF's work product is a coherent whole.  But it's hard to get started if you don't already have the connections to have your work sponsored by somebody who already knows their way around the IETF's idiosyncrasies.  I'm doing some of that sponsoring myself now for the people from tc39 who are trying to get the IETF to look at defining an extended datetime format.
> 
> Cheers,
> 
> Bron.
> 
> On Tue, Feb 23, 2021, at 11:07, Fernando Gont wrote:
>> Folks,
>> 
>> https://www.ietf.org/archive/id/draft-gont-diversity-analysis-00.txt <https://www.ietf.org/archive/id/draft-gont-diversity-analysis-00.txt>
>> 
>> (https://datatracker.ietf.org/wg/gendispatch/about/ <https://datatracker.ietf.org/wg/gendispatch/about/>). But given the 
>> e-mail: [email-masked] <mailto:[email-masked]>
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   [email-masked] <mailto:[email-masked]>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Feb 2021 05:40:23 -0300

Hello, Dominique,

On 23/2/21 05:18, Dominique Lazanski wrote:
> I would support Bron’s experience and also say that there are several 
> other barriers to entry that I’ve found. One is different approaches to 
> topics than the mainstream IETF approach held by most IETF attendees. I 
> am thinking about privacy/encryption, for example.

Could you elaborate a bit more on this one? e.g., some example (so that 
we can understand better what you mean)... and if you can think of 
anything that might be done to improve things in this respect, that 
would also be nice.

> But the other big 
> barrier to entry is the draft upload tools. For a new person attending 
> for the first time the tools are a relic of 1990 of thereabouts and can 
> be confusing and difficult.

FWIW, we have already started to work on a revision of the draft 
(working copy at: 
https://github.com/fgont/diversity/blob/main/draft-gont-diversity-analysis-01.txt), 
and this is what we currently have in the Section 8.2 of the upcoming rev:

---- cut here ----
8.2.  Difficulty in Authoring and Submitting Internet-Drafts

    There are so many formatting rules that an Internet-Draft (and
    eventually an RFC) needs to comply to, that in practice the only
    reasonable way create and submit an Internet-Draft is via the set of
    tools available at: https://tools.ietf.org/ . Tools such as xml2rfc
    are of a lot of help to produce documents that comply with the
    Internet-Draft formatting rules -- but its error messages might
    result cryptic to the unexperienced user.

    The number of tools has expanded so much that they probably deserve
    their own guidelines.  And existing guidelines such as
    [ID-Guidelines] should probably be updated with the assumption that
    Internet-Drafts will be produced with the set of available tools.

       This means that e.g. it becomes less important to the Internet-
       Draft author what formatting rules a document needs to comply to,
       since the existing tools will guarantee such compliance.  On the
       other hand, an author may benefit from guidelines on how to use
       the set of available tools.
---- cut here ----

Is there anything you'd suggest adding to it?

> In any case, I shall join the gendispatch group to discuss further!

Please do, but also feel free to discuss it here if you wish, too.

Thanks a lot!

Regards,

---

From: Dominique Lazanski <[email-masked]>
Date: Tue, 23 Feb 2021 09:50:06 +0100

> On 23 Feb 2021, at 09:40, Fernando Gont <[email-masked]> wrote:
> 
> Hello, Dominique,
> 
>> I would support Bron’s experience and also say that there are several other barriers to entry that I’ve found. One is different approaches to topics than the mainstream IETF approach held by most IETF attendees. I am thinking about privacy/encryption, for example.
> 
> Could you elaborate a bit more on this one? e.g., some example (so that we can understand better what you mean)... and if you can think of anything that might be done to improve things in this respect, that would also be nice.
> 

Sure! This is purely my experience, but I have found it challenging (and hostile) to engage in controversial topics which don’t have consensus. I think encryption is the most obvious one and consolidation another. I don’t want to dwell on the issues, but would rather suggest solutions. I think it would be great to organise open sessions of an hour just on these topics focused specifically on having difficult and challenging conversations only about one topic. Obviously we have open IAB, plenary and etc, but a focused, short meeting would be one idea.

> 
>> But the other big barrier to entry is the draft upload tools. For a new person attending for the first time the tools are a relic of 1990 of thereabouts and can be confusing and difficult.
> 
> FWIW, we have already started to work on a revision of the draft (working copy at: https://github.com/fgont/diversity/blob/main/draft-gont-diversity-analysis-01.txt), and this is what we currently have in the Section 8.2 of the upcoming rev:
> 
> ---- cut here ----

This is great news! I will definitely go to git and add a few things.

Dominique

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Feb 2021 09:51:06 +0000

Hi Fernando,

I just took a quick look at the document and I missed one point that increasingly worries me working in the IETF, namely the increasing number of participants who are not interested to write any code*.
I would include this aspect under diversity, particularly when talking about the new leadership election cycles.

Participating in some working groups I more and more get the impression to sit in a document writing class rather than in an Internet engineering organization.

Ciao
Hannes

*: I am also including authors of protocol specifications that do not implement their own specifications.

-----Original Message-----
From: ietf <[email-masked]> On Behalf Of Fernando Gont
Sent: Tuesday, February 23, 2021 1:07 AM
To: [email-masked]' <[email-masked]>; GENDISPATCH List <[email-masked]>; Keith Moore <[email-masked]>
Subject: Diversity and Inclusiveness in the IETF

Folks,

We have submitted a new I-D, entitled "Diversity and Inclusiveness in the IETF".

The I-D is available at:

We expect that our document be discussed in the gendispatch wg (https://datatracker.ietf.org/wg/gendispatch/about/). But given the breadth of the topic and possible views, we'll be glad to discuss it where necessary/applicable/desired.

As explicitly noted in our I-D, we're probably only scratching the surface here -- but we believe that our document is probably a good start to discuss many aspects of diversity that deserve discussion.

Thanks!

Regards,

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Feb 2021 11:01:09 +0000

Dominique, could you expand on your privacy/encryption experience a little bit?

Ciao
Hannes

From: ietf <[email-masked]> On Behalf Of Dominique Lazanski
Sent: Tuesday, February 23, 2021 9:18 AM
To: Bron Gondwana <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Diversity and Inclusiveness in the IETF

Dominique

On 23 Feb 2021, at 05:19, Bron Gondwana <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Fernando,

Cheers,

Bron.

The I-D is available at:

Thanks!

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

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]<mailto:[email-masked]>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Feb 2021 13:37:10 +0000

Hiya,

On 23/02/2021 08:18, Dominique Lazanski wrote:
> One is different approaches to topics than the mainstream IETF
> approach held by most IETF attendees. 
> I am thinking about privacy/encryption...
That topic differs from others in this discussion
in that the IETF has repeatedly debated it in lots
of detail, and with many different opinions being
factored in, and over decades, and has established a
set of rough consensus positions after significant
informed debate on a topic where IETF participants
are pretty well qualified to claim expertise.

Other aspects of this discussion relate to things
where we've not really noticed that we even have a
position, e.g. the use of terms that were considered
ok in the past, but aren't today, or where we're not
at all expert, e.g. handling our own biases.

I think our approach to handling claims that we'd
be better to change should validly differ in the
above two cases - it is *much* harder to bring
really new information in the former case than in
the latter for example.

Cheers,
S.

---

From: Dan Harkins <[email-masked]>
Date: Tue, 23 Feb 2021 06:21:23 -0800

Hi Hannes,

> I just took a quick look at the document and I missed one point that increasingly worries me working in the IETF, namely the increasing number of participants who are not interested to write any co…

   That's a great point! One of the attractions (to me, at least) of the 
IETF was
that it wasn't some guy with some slides and a story. It was someone 
with an idea,
a reference implementation of the idea, and results of (partially) 
deploying the
code and seeing what it did. That was very compelling. We learned things 
from the
running code that actually helped improve the specification. We were doing
engineering!

   When I think back on it, such a demand to have running code must've 
been quite
a barrier to inclusiveness (which might've had an impact on some axes of 
diversity)
for some. But isn't that a good thing? Doesn't a certain amount of 
exclusivity, or
demand for some standard for participation, result in better product? I 
think it
does. We should be engineering the Internet. I hope we don't throw out 
the baby
with the bathwater when we get so focused on diversity and inclusion.

   Yes, there has been less and less a demand on running code (sadface 
emoji) and
I share your worry. Not only are some participants not interested in 
writing any
code, we are also coming up with work that does not require any code at 
all. Look
at the WG that people want to charter here! There is no demand for any code
whatsoever. And there is even a reluctance to state a linkage between 
proposal and
desired result, the basis of our engineering-- "how we get there with 
this idea" is
not to be discussed. This is all very worrying.

   regards,

   Dan.

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 23 Feb 2021 16:07:28 +0100 (CET)

> Il 23/02/2021 01:07 Fernando Gont <[email-masked]> ha scritto:
> 
>  
> Folks,
> 

Thanks for starting this. I also wanted to write something, but could not find the time. I wanted to work on a description of factors and dimensions that could make people feel out of place in an organization, both in professional and social terms, or make it harder to participate. I think that the right approach is first to document all the potential issues, and then to discuss whether each of them can and should be addressed (in some cases, there might even be groups that you do not want to include, but that's a separate discussion from documenting that they exist).

I only got as far as writing down a bullet list of points, so I'm sharing it - you covered part of it already, not everything. I'll be happy to contribute text if I have time, but in the meantime, here it is: 

open prejudice
- harassing behaviour towards specific groups
- harassing behaviour in interpersonal terms (rudeness etc)

style of participation
- tone and attitude of conversations (aggressiveness, lack of willingness to listen and compromise, etc)
- need to "speak up" (often in public at a microphone) to get heard
- disagreement can only be expressed by blocking consensus
- availability of time to follow and show up at the right moment

direct lack of diversity
- gender, ethnicity, geography, age, social and professional background, type of employer
- lack of "people like me", difficulty in "belonging" during meetings
- diversity in values and views of the world 

language
- languages (not) spoken, no translations
- general american english jargon
- technical jargon
- offputting words

fees
- general vs per group/per number of events
- cost of travel to physical meetings
- cost of instruments for virtual meetings

timezones, locations

club for regulars
- learning curve on how to behave
- access to documents and archives
- lack of transparency on who people are, "insider only" conversations referring to old events not documented
- facilitations only for old timers / privileges by "how much you have contributed"

industry/stakeholder dominance
- considering viewpoints from specific industry sectors more/less important than others
- considering viewpoints from specific stakeholder groups more/less important than others
- big companies vs SMEs vs community projects
- proprietary/patent-oriented vs open source
- implementation-first vs specification-first

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Kyle Rose <[email-masked]>
Date: Tue, 23 Feb 2021 10:18:13 -0500

Good list. I think one thing to keep in mind is that not all of these have
solutions, and in some cases are zero-sum. IMO, we should be careful to
limit the scope to identifying the obstacles to inclusion, and leave
solutions to later steps.

direct lack of diversity
> - diversity in values and views of the world

One big problem in this category that should be called out explicitly is
underrepresentation from areas of the world with networks that look
entirely unlike what we have in the West. Africa, in particular, has very
little wired coverage.

> - cost of travel to physical meetings

This is a big one. I wouldn't put it under "fees", but rather "cost of
involvement". If time were the only factor, remote participation would be
doable; but the hallway conversations at thrice-yearly meetings have no
effective substitute. (This IMO is an argument in favor of reducing
in-person meetings to 1x/year, and to help subsidize the cost of travel and
lodging for folks whose needs are underrepresented in the IETF... but now
I'm getting into potential solutions.)

Kyle

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Feb 2021 12:20:59 -0300

On 23/2/21 06:51, Hannes Tschofenig wrote:
> Hi Fernando,
> 
> I just took a quick look at the document and I missed one point that
> increasingly worries me working in the IETF, namely the increasing
> number of participants who are not interested to write any code*.

It could be the case that people are not interested, or that they don't 
have the time, or that they are not familiar with an open source project 
to contribute code. It could be any of them, and it's probably difficult 
to tell.

In some cases, whether a WG gives value to an implementation might 
encourage or discourage work on an implementation.

And then there are other things, such as:
* Each open source project has it's own culture.

* Some are very welcoming. Others not so much.

* Some will help for you to implement things, others (usually smaller) 
projects might try or want to implement stuff themselves.

And, as with other things, whether somebody has support from his/her 
employer will also have an effect -- e.g., if you have a pay job and do 
IETF stuff independently, then you probably won't have enough time to 
work on a draft and participating in the discussions, let alone 
implementing it.

Then there are other things. e.g., I once did multiple implementations 
fo a document I had co-authored, and provided pointers to the 
implementations in an appendix. One IETF participant took the time to 
ask each project to back out the commits "because the document had not 
yet become an RFC".

> I would include this aspect under diversity, particularly when
> talking about the new leadership election cycles.

Could you elaborate a bit more on this one? And what you'd like to see?

> Participating in some working groups I more and more get the
> impression to sit in a document writing class rather than in an
> Internet engineering organization.

One possible explanation is that energy is a finite resource: the more 
bureaucracy and politics involved, the lesser the time to commit to 
other things.

Thanks,

---

From: Juliana Guerra <[email-masked]>
Date: Tue, 23 Feb 2021 12:00:30 -0500

Hi Fernando, thanks for this important document. Some comments:

- This sentence "Lack of diversity in IETF groups and leadership roles
has a direct effect on IETF participation, as a result of" is confusing,
and is only followed by a description in detail of "lack of diversity."

- For language inclusiveness, I recommend to replace "his" with "their"
or "his or her" in cases such as "WG chair leaves his role"

- With regard to Section 11.2, I think it's necessary to say something
more about the "bit of an art to using [email] efectively". Maybe
describing some specific IETF lists dynamics.

- In section 11.3 Comfort Zone, I missed at least a comment about the
difficulties and necessary compromises to deal with disagreement and
difference. I think it would be useful to mention RFC 7154 and RFC 7776,
and consider the list Vittorio B shared before.

And two comments following the conversation here:

- I agree that it would be better for the draft to focus on identifying
obstacles to inclusion.

- I think the "mostly running code" issue is out of scope in this draft.

Regards!

Juliana G

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 23 Feb 2021 18:13:35 +0100

On 2021-02-23, at 16:20, Fernando Gont <[email-masked]> wrote:
> 
> In some cases, whether a WG gives value to an implementation might encourage or discourage work on an implementation.

Not an unimportant point.

If the perception of people bringing work is that acceptance in the IETF is mostly aleatoric, they’ll think twice before investing in an implementation before significant advancement.

This is particularly true if they already have a proprietary implementation that will need significant work before it makes all of IETF’s checkmarks.

I’m not saying anything of this is wrong or actually fixable.

Grüße, Carsten

---

From: Jay Daley <[email-masked]>
Date: Wed, 24 Feb 2021 09:16:00 +1300

Thanks for attempting a comprehensive overview.

Some things jumped out at me:

1.  At times the draft appears to conflate issues of 'diversity/inclusion’ with issues of ‘participation’ in general.  In case the difference is not clear - an issue with participation only becomes an issue with diversity/inclusion when one specific group of people is disproportionately affected.  Specific examples of where it does that are sections 7 (Processes), 8 (Difficulties in joining the IETF), 11.2 (Using email effectively) and 11.3 (Comfort zone), all of which are general issues with participation.  

2.  At times the draft also appears to conflate issues of 'diversity/inclusion' with issues of 'conflict of interest', where that conflict of interest comes from multiple people having the same employer.  For example:

- From section 6

	Process fairness by having a very small number of interests
	judging WG consensus, community consensus, and appeals.

	Leadership selection fairness by having a limited number of
	interests participating in the NOMCOM and IAB.

Jay

> On 23/02/2021, at 1:08 PM, Fernando Gont <[email-masked]> wrote:
> 
> Folks,
> 
> The I-D is available at: https://www.ietf.org/archive/id/draft-gont-diversity-analysis-00.txt
> 
> Gendispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gendispatch
> 

-- 
Jay Daley
IETF Executive Director

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 23 Feb 2021 21:55:46 +0100

Hiya,

Thanks for this. I will have a better look later, but a couple things stood out from an initial cursory read:

- A reference to the observations and conclusions from RFC7704 might be useful

Under 3. Terminology:
- I would suggest changing 'ethnic' to 'cultural'
- Consider replacing:

   o  a range of different social and ethnic backgrounds

with:

   o  different socioeconomic and sociocultural backgrounds

- Consider adding:
   o different physical and neurophysical abilities

- Consider replacing:
"diversity" has multiple axes

with:

"diversity" has many different aspects

Under 4. Perceived Return of Investment (ROI)
- I am a bit confused by this argument, not sure I fully follow it. Apart from maybe having some comprehension or consistency issues, it has the risk of economic reductionism. I think the rewards from different members of the community are different and not necessarily tied to financial gains. 

- Consider changing:

developing countries

with:

low- and middle-income countries

5.  Effects of Current Participation 
- This section would definitely benefit from a link to RFC7704 as well as RFC8719

8.  Difficulty in Joining the IETF
Would benefit from a mention of the Tao and the EDU-TEAM
- 

9.  Economic Constraints
- Could benefit from mentioning time constraints.

11.3 Comfort zone
- This individualizes a problem that might not be individual but a function of the organization or group of people acting in it. 

Another point might be the appreciation (or lack thereof) of different kinds of knowledge and expertise. 

Best,

Niels

-- 
Niels ten Oever, PhD
Postdoctoral Researcher - Media Studies Department - University of Amsterdam
Research Fellow - Centre for Internet and Human Rights - European University Viadrina
Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas

W: https://nielstenoever.net
E: [email-masked]
T: @nielstenoever
P/S/WA: +31629051853
PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3

Read my dissertation 'Wired Norms' here: https://pure.uva.nl/ws/files/50781961/Thesis.pdf

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Feb 2021 10:50:28 +1300

Hannes,

> I just took a quick look at the document and I missed one point that increasingly worries me working in the IETF, namely the increasing number of participants who are not interested to write any co…

Can you justify "increasing number"? I don't mean compared to 1986, but compared (for example) to 2011? As long as I can remember, people have been concerned about participants who are "goers" rather than "doers" at meetings, and you seem to be adding a further concern, "doers" whose action is to write text rather than write code.

Also, you don't mention operators, whose role is not to write code at all but whose contribution to the IETF is essential. So that's another category of "doers".

I'd like to see some actual facts about these various categories of "doers". What % were they 10 or 20 years ago, and what % are they now? Has the hackathon changed the numbers? Etc.

> I would include this aspect under diversity, particularly when talking about the new leadership election cycles.

Yes, it should be on NomCom's radar. The need for enough ops people has long been understood, but recent development experience is also relevant.

> Participating in some working groups I more and more get the impression to sit in a document writing class rather than in an Internet engineering organization.

Since our principal output is text, that isn't so surprising, but I think there's a case for sending any spec that does not adhere to RFC7942/BCP205 back to the WG.

> *: I am also including authors of protocol specifications that do not implement their own specifications.

That's a bit cruel. In larger organisations, it might be totally infeasible. But again, RFC7942 is our friend.

Regards
    Brian

---

From: Mary Barnes <[email-masked]>
Date: Tue, 23 Feb 2021 16:26:16 -0600

Hannes,

Ditto to what Brian said.

I no longer write code although I have written LOTS of code for lots of
systems for nearly 20 years that have run in the real world for decades
(there's still Nortel DMS cranking away out there).   And, while I write
specs, I do work very closely with those implementing the specs and I don't
write specs for things that aren't being considered as potential
products/real systems.    I ask lots of questions when I'm working with
those coding, so I'm confident folks do understand what it is they're
implementing.   I worked with  contractors implementing ACME for one
company a few years back and I knew they didn't understand because I could
see the questions they were asking in the open forums and I knew they were
misinterpreting those responses.  I found the place in the Let's Encrypt
code where they needed to hook in the new code and I was almost at the
point of writing the code myself over a weekend with my son, but it was
their job.

There's far more value in my being able to educate the folks coding,
provide architectural feedback, talk to vendors to ensure that what they
are providing meets the requirements (security in particular) as well as
testing the system after it's been coded and providing feedback.   And, in
my experience, the coding is the easy part. When I was a developer, that
was the fun part - the reward after you got all the required documentation
written.   And, I always develop specs from the perspective that a
developer needs to use that as the basis for writing code, so I know how I
would want things written to facilitate that process.

So, your point about people writing specs not being the ones writing code
is a little judgemental.  I would say "elitist" and that's how it comes
off, but I don't consider those that write code necessarily to be the
elite.  But, it is this notion that there are certain types of people at
IETF that are amongst the elite that is one of the issues around
inclusion.

Regards,
Mary.

On Tue, Feb 23, 2021 at 3:51 PM Brian E Carpenter <
[email-masked]> wrote:

> increasingly worries me working in the IETF, namely the increasing number
> of participants who are not interested to write any code*.
>
> Can you justify "increasing number"? I don't mean compared to 1986, but
> compared (for example) to 2011? As long as I can remember, people have been
> concerned about participants who are "goers" rather than "doers" at
> meetings, and you seem to be adding a further concern, "doers" whose action
> is to write text rather than write code.
>
> Also, you don't mention operators, whose role is not to write code at all
> but whose contribution to the IETF is essential. So that's another category
> of "doers".
>
> I'd like to see some actual facts about these various categories of
> "doers". What % were they 10 or 20 years ago, and what % are they now? Has
> the hackathon changed the numbers? Etc.
>
> > I would include this aspect under diversity, particularly when talking
> about the new leadership election cycles.
>
> Yes, it should be on NomCom's radar. The need for enough ops people has
> long been understood, but recent development experience is also relevant.
>
> > Participating in some working groups I more and more get the impression
> to sit in a document writing class rather than in an Internet engineering
> organization.
>
> Since our principal output is text, that isn't so surprising, but I think
> there's a case for sending any spec that does not adhere to RFC7942/BCP205
> back to the WG.
>
> > Ciao
> > Hannes
> >
> That's a bit cruel. In larger organisations, it might be totally
> infeasible. But again, RFC7942 is our friend.
>
> Regards
>     Brian
> >
> > To: [email-masked]' <[email-masked]>; GENDISPATCH List <
> [email-masked]>; Keith Moore <[email-masked]>
> > We expect that our document be discussed in the gendispatch wg (
> https://datatracker.ietf.org/wg/gendispatch/about/). But given the
> breadth of the topic and possible views, we'll be glad to discuss it where
> necessary/applicable/desired.
> >
> surface here -- but we believe that our document is probably a good start
> to discuss many aspects of diversity that deserve discussion.
> >
> > Thanks!
> >
> > Regards,
> > --
> > Fernando Gont
> > SI6 Networks
> > IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> >
>
> --
> Gendispatch mailing list
> [email-masked]

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 23 Feb 2021 23:26:36 +0100

> On Feb 23, 2021, at 10:50 PM, Brian E Carpenter <[email-masked]> wrote:

Yep.

PCH has been an active participant in the IETF for some 28 years, and we’re not a code-writing shop, we’re an operator.  We have very strong feelings about what’s needed, and we also know that we aren’t going to be the ones writing that code, we’re going to be the ones fielding it and trying to make it scale.  So, yes, we care about the success of the IETF and the open standards process and multistakeholderism, because it’s all vital to our being able to hold up our end of things.

Writing code is one critical aspect of the IETF.  Writing specifications is another critical aspect of the IETF.  Testing interoperability is yet another.  None of these stand alone, and none work without the others.

                                -Bill

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Feb 2021 23:06:15 -0300

Hello, Jay,

Thanks so much for your comments! In-line....

On 23/2/21 17:16, Jay Daley wrote:
> 1.  At times the draft appears to conflate issues of
> 'diversity/inclusion’ with issues of ‘participation’ in general.  In
> case the difference is not clear - an issue with participation only
> becomes an issue with diversity/inclusion when one specific group of
> people is disproportionately affected.

The two are indeed related: the more "expensive" (in multiple axes) it 
is to participate, the more the system benefits those with more resources.

e.g., if you need four full working-days to effectively participate in 
the IETF, you'll only be able to participate if somehow you can make a 
living out of participation.

> Specific examples of where it does that are sections 7 (Processes),

The more something is loosely specified, the more discretionary actions 
are possible, (as noted, in *some* cases might indeed beneficial).

That means that a newcomer is at the will of such discretionary actions.

And since the process is biased in favor of a sub-set of individuals and 
organizations, and that same group generally runs the process, then 
discretionary actions would not be unlikely to reflect the interests of 
said group.

THere is the saying that "the law is there to protect the weaker, 
because the strong probably don't need protection".

> 8 (Difficulties in joining the
> IETF), 11.2 (Using email effectively) and 11.3 (Comfort zone), all of
> which are general issues with participation.

They are general issues which do not affect all people the same.

For example, a rude environment can be seen as "a general issue with 
participation". However, a rude environment will not affect all 
participants in the same way. Some will walk away, others will 
nevertheless stay.

> 2.  At times the draft also appears to conflate issues of
> 'diversity/inclusion' with issues of 'conflict of interest', where
> that conflict of interest comes from multiple people having the same
> employer.  For example:
> 
> - From section 6
> 
> Process fairness by having a very small number of interests judging
> WG consensus, community consensus, and appeals.
> 
> Leadership selection fairness by having a limited number of interests
> participating in the NOMCOM and IAB.

And the two are indeed related. When conflicts of interest 
systematically affect an organization, there's a whole range of peo 
people that will walk away.

e.g., if contributions are treated/processed differently depending on 
the affiliation of the author, that certainly results in diversity and 
inclusivity issues.

One way or another, if the same company funds people that submits 
proposals, and also fund the people that judge such proposals, there is 
going to be an obvious conflict of interest.

Diversity in IETF roles, nomcom, etc., would mean that such conflicts of 
interest can be reduced to a minimum.

Thanks,

---

From: S Moonesamy <[email-masked]>
Date: Tue, 23 Feb 2021 20:15:34 -0800

Hi Juliana,
>and consider the list Vittorio B shared before.

My experience of RFC 7776 is that it does not work.

Regards,
S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 24 Feb 2021 17:21:36 +1300

> My experience of RFC 7776 is that it does not work.

Can you please provide some more details of that assertion, suitably anonymized?

Regards
    Brian

---

From: S Moonesamy <[email-masked]>
Date: Tue, 23 Feb 2021 20:41:12 -0800

Hi Brian,
>Can you please provide some more details of that assertion, suitably 

There was a report which was filed in August 2020.

Regards,
S. Moonesamy

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Feb 2021 07:22:24 +0000

Hi Mary,

It is great to hear that you also consider coding the fun part.

Note that I am not saying that those who do not write code are not allowed to participate in the working group. Far from the truth. If you have read through the OAuth discussion you may have noticed that I am a big advocate of involving an wide range of expertise.

To the point: IMHO there has to be a difference between the document author and other participants, most of which are passive. I see the role of a document author being more than just the person writing the text. Hopefully that person cares enough about the work he or she proposes to go the extra mile. If a document author does not care about implementing his or her protocol then we have a problem.

Implementations, even if they are just prototypes, provide valuable feedback during the work on a specification. Someone has to do this work. Writing an implementation of a protocol can easily be several times the effort of writing a specification.
I doubt it is a good approach to just wait till someone does the work for you.

I am seeing this happening today in the IETF in many working groups.

Do you agree that

  *   Implementations provide valuable feedback during the standardization work,
  *   Someone has to do the implementation work,
  *   Implementations are time consuming (even if they are fun for many to write)?

The culture of hands-on work needs to be more than a responsibility of the document authors. It is a culture that has to cut across the organization, from working group chairs to the IESG. Currently, there are disincentives to work on code as a document author.

I want people with hands-on experience in the leadership of an engineering organization. For me this is a form of diversity.

I hope this clarifies my point and convinces you that this is not about an elitist view.

Ciao
Hannes

From: Mary Barnes <[email-masked]>
Sent: Tuesday, February 23, 2021 11:26 PM
To: Brian E Carpenter <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Fernando Gont <[email-masked]>; [email-masked]; GENDISPATCH List <[email-masked]>; Keith Moore <[email-masked]>
Subject: Re: [Gendispatch] Diversity and Inclusiveness in the IETF

Hannes,

I no longer write code although I have written LOTS of code for lots of systems for nearly 20 years that have run in the real world for decades (there's still Nortel DMS cranking away out there).   And, while I write specs, I do work very closely with those implementing the specs and I don't write specs for things that aren't being considered as potential products/real systems.    I ask lots of questions when I'm working with those coding, so I'm confident folks do understand what it is they're implementing.   I worked with  contractors implementing ACME for one company a few years back and I knew they didn't understand because I could see the questions they were asking in the open forums and I knew they were misinterpreting those responses.  I found the place in the Let's Encrypt code where they needed to hook in the new code and I was almost at the point of writing the code myself over a weekend with my son, but it was their job.

There's far more value in my being able to educate the folks coding, provide architectural feedback, talk to vendors to ensure that what they are providing meets the requirements (security in particular) as well as testing the system after it's been coded and providing feedback.   And, in my experience, the coding is the easy part. When I was a developer, that was the fun part - the reward after you got all the required documentation written.   And, I always develop specs from the perspective that a developer needs to use that as the basis for writing code, so I know how I would want things written to facilitate that process.

So, your point about people writing specs not being the ones writing code is a little judgemental.  I would say "elitist" and that's how it comes off, but I don't consider those that write code necessarily to be the elite.  But, it is this notion that there are certain types of people at IETF that are amongst the elite that is one of the issues around inclusion.

Regards,
Mary.

On Tue, Feb 23, 2021 at 3:51 PM Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
Hannes,

Regards
    Brian
> From: ietf <[email-masked]<mailto:[email-masked]>> On Behalf Of Fernando Gont
> To: [email-masked]<mailto:[email-masked]>' <[email-masked]<mailto:[email-masked]>>; GENDISPATCH List <[email-masked]<mailto:[email-masked]>>; Keith Moore <[email-masked]<mailto:[email-masked]>>

--
Gendispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/gendispatch
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Feb 2021 08:47:40 +0000

Hi Brian,

Thanks for the questions.

> Can you justify "increasing number"? I don't mean compared to 1986, but compared (for example) to 2011? As long as I can remember, people have been concerned about participants who are "goers" rath…

[Hannes] I started noticing it after the IETF started the hackathons, which gave implementers more visibility. In the groups I participate in, I regularly ask around for volunteers to join the hackathon. Then, you get an idea who is interested to participate and who isn't. The hackathons are also a "light" form of coding because you are selecting a really small specification aspect only. Hence, the bar is pretty low for entry. At f2f hackathons you also have a number of people joining who use the event to chat. So, you have to take this into account as well.

[Hannes] Since I am attending a small number of the working groups I am obviously curious whether others have made a similar observation. Maybe I am hanging around in the "wrong" groups. I also attend OAuth and TLS, which are different. In those two groups a lot of implementation and deployment work is happening.

> Also, you don't mention operators, whose role is not to write code at all but whose contribution to the IETF is essential. So that's another category of "doers".

[Hannes] Actually, I wouldn't make this distinction because it is really about the persons involved. Every bigger organization has people who are more disconnected from the engineering than others. That's totally fine. Also consider that we are not talking about writing product-quality implementations in this conversation. Those implementations are often, with the level of specialization in our world, created and maintained by bigger teams in a company. With our regularly changing drafts I would recommend to wait with product-quality code till the specification matures or is completed.

> I'd like to see some actual facts about these various categories of "doers". What % were they 10 or 20 years ago, and what % are they now? Has the hackathon changed the numbers? Etc.

[Hannes] We could collect some numbers. I doubt it would be easy to collect them from the past. We could re-use the document shepherd writeup. Already today we (at least Rifaat and I do it) indicate whether there are implementations of a specific specification. We could add information about testing, hackathon participations, and details about the implementations. We could capture whether the authors themselves have worked on the code or someone else. If it was someone else, we could try to loop them into the discussion to collect the feedback.

> Since our principal output is text, that isn't so surprising, but I think there's a case for sending any spec that does not adhere to RFC7942/BCP205 back to the WG.

[Hannes] On the surface, it looks like we are producing text. But actually we want much more. We want running code (in the sense of deployed code) and we should expand it to "running secure code".
I think that this is the biggest mental obstacle. If we believe our work is done when the specification is done, then we will fail to reach the full potential of our work. I understand that this message is inconvenient because many participants have difficulties to influence the deployment or even implementations. This is also the cause of a lot of frustration in the IETF work because person A says or writes "I went feature foo." but persons B and C then need to implement 'foo' and then deploy it. Needless to say that persons B and C are less excited about doing the work for person A. IMHO this is the root cause of many conflicts as far as I can see.

> That's a bit cruel.

[Hannes] The IETF mission statement says that we care about "engineering quality" and "running code" then we have to figure out how we get there. As mentioned in other conversations, for me this means more use of formal methods for security protocols and implementations supporting specifications. I would also point to the need for testing but I am already now stretching the limits of what people are willing to hear...

> In larger organisations, it might be totally infeasible. But again, RFC7942 is our friend.

[Hannes] As mention above, I am not asking for product-quality code. For what I am trying to accomplish, namely to feed implementation experience back into the specification work, I would already be happy to get the implementers involved. Having worked in a big telco equipment manufacturer myself I know that the implementers do not start their work until the specification is finished (or even years later). So, you would need some prototyping work while you are writing the spec. At least when I was working for this unnamed telco equipment manufacturer, developing prototypes and PoCs was in scope of my work.

Ciao
Hannes

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 24 Feb 2021 10:39:44 +0100 (CET)

>     Il 24/02/2021 08:22 Hannes Tschofenig <[email-masked]> ha scritto:
> 
> 
The question is whether you *only* (mostly) want coders in the leadership, or whether you *also* want coders in the leadership. This makes a lot of difference in evaluating your position.

Coming from my own IETF experience, which of course is just about a small subset of everything that is happening here, I'd say that the IETF has the opposite problem - the IETF does not seem to have a way, or even the desire, to acquire non-technical perspectives on what it is doing, so whenever a new protocol ends up prompting significant regulatory, business or social changes, they seem to come unexpectedly; the non-technical stakeholders that were not involved in the design phase get mad at the IETF, and the people at the IETF are surprised (sometimes even offended) by that reaction. And then you get a debate on whether code is law or not and whether the socio-economic implications of new technologies have to be considered by the technologists, which I thought we had closed forever at the turn of the century.

(But sorry, possibly this is not a discussion in topic for gendispatch - it is more for a new WG on diversity and inclusiveness ;-) )

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 24 Feb 2021 11:36:05 +0000

Hi Vittorio,

I also want people with hands-on experience in leadership. In general, I wanted to raise the importance of skills in this discussion. For some reason it seems to have gotten lost. You added even more requirements below, which I am also fine with.

From my experience in the IAB I must say it is not so easy to attract the regulatory community and economist. We had some success with the former category simply because some IETF people ended up working in the regulatory space and some of the working groups had pretty strong ties to the regulatory space (e.g. emergency services, privacy, telecommunications). Henning Schulzrinne, for example, worked for the FCC and shared his experience at IAB plenaries. We also tried to involve economists and the work by Eliot needs to be mentioned, see https://www.iab.org/activities/workshops/itat/. I am not sure where this effort ended up.

Would I like to see a guy like Henning with his IETF / FCC experience in the IETF leadership. Definitely. Would he want to do that? Most likely not.

Ciao
Hannes

From: Vittorio Bertola <[email-masked]>
Sent: Wednesday, February 24, 2021 10:40 AM
To: Hannes Tschofenig <[email-masked]>
Cc: GENDISPATCH List <[email-masked]>; [email-masked]
Subject: Re: [Gendispatch] Diversity and Inclusiveness in the IETF

Il 24/02/2021 08:22 Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> ha scritto:

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]<mailto:[email-masked]>
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 24 Feb 2021 15:07:36 +0000

> PCH has been an active participant in the IETF for some 28 years, and we’re not a code-writing shop, we’re an operator.  We have very strong feelings about what’s needed, and we also know that we a…

Totally agree with Bill here, speaking as another operator. Seeing if new stuff in development is deployable at scale is the "running" part of "running code". :-)

JL

---

From: Eliot Lear <[email-masked]>
Date: Wed, 24 Feb 2021 16:43:03 +0100

Meanwhile…

… I think the draft that Keith and Fernando wrote is a good start.

The organization might need a bit of work, but I like the idea of having a menu from which we can pick in order to address some, but perhaps not all, of the issues.

Also, first, it would be good to quantify the situation.  In what dimensions are we diverse and in what dimensions are we not?  Second, for each dimension in which we are not, some discussion as to which of the issues raised hits which dimension.  That is, draw out the possible causalities.

It could be that some logic is wrong.  What are the questions that need to be asked and answered to validate the assertions being made, and which parties are in a good position to ask, and which are in a good position to answer?

This sets up an opportunity to see that any changes we make will likely have some effect.

Eliot

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 24 Feb 2021 16:59:28 +0100

> Also, first, it would be good to quantify the situation.  In what dimensions are we diverse and in what dimensions are we not?  Second, for each dimension in which we are not, some discussion as to…

I understand the interest in quantification, and it might be useful in some cases, but I would like to underline that not everything is quantifiable in a meaningful way.

See for instance: https://hbr.org/2011/05/the-risks-of-quantification

Best,

Niels

---

From: Mary Barnes <[email-masked]>
Date: Wed, 24 Feb 2021 10:17:34 -0600

On Wed, Feb 24, 2021 at 1:22 AM Hannes Tschofenig <[email-masked]>
wrote:

> Note that I am not saying that those who do not write code are not allowed
> to participate in the working group. Far from the truth. If you have read
> through the OAuth discussion you may have noticed that I am a big advocate
> of involving an wide range of expertise.
>
>
>
> To the point: IMHO there has to be a difference between the document
> author and other participants, most of which are passive. I see the role of
> a document author being more than just the person writing the text.
> Hopefully that person cares enough about the work he or she proposes to go
> the extra mile. If a document author does not care about implementing his
> or her protocol then we have a problem.
>
>
>
> Implementations, even if they are just prototypes, provide valuable
> feedback during the work on a specification. Someone has to do this work.
> Writing an implementation of a protocol can easily be several times the
> effort of writing a specification.
>
>    - Implementations provide valuable feedback during the standardization
>    work,
>
> [MB] I totally agree. [/MB]

>
>    -
>    - Someone has to do the implementation work,
>
> [MB] Definitely.  And, per the point brought up about operators, they
generally aren't the ones writing the code, their vendors are. [/MB]

>
>    -
>    - Implementations are time consuming (even if they are fun for many to
>    write)?
>
> [MB]  They can be very time consuming and in my experience the issue is
more that folks are often busy working other products out while I might be
working on specs, so they often don't have the time to dedicate while specs
are being written.  And, in the places I've worked unless there's a spec in
place, folks aren't going to be implementing something.  That wasn't the
case in one of the groups I was with in Nortel way back when, but it has
been in recent years (partly because I fell back in time to the more
traditional telecom world where that is the standard development process).
[/MB]

>
>    -
>
>
>
> The culture of hands-on work needs to be more than a responsibility of the
> document authors. It is a culture that has to cut across the organization,
> from working group chairs to the IESG. Currently, there are disincentives
> to work on code as a document author.
>
[MB] I see disincentives in that some companies have people in roles where
they wouldn't have time to code because they're doing work well beyond IETF
and within their organization, they are just not viewed as part of the
group that codes.  You get into corporate politics and people not wanting
people in other groups to do work that they view as the purview of their
group.  I can't tell you how much of that I've dealt with.   [/MB]

>
>
> I want people with hands-on experience in the leadership of an engineering
> organization. For me this is a form of diversity.
>
[MB] The hands-on experience is great and certainly brings
significant value.  But, there's also diversity in terms of industries that
use the output of IETF and the sort of work they need IETF to do.
Certainly, I think the majority of the work is about people contributing to
and reviewing specs from the perspective of whether it's good enough that
you could write working, interoperable code based on the spec.  But, having
people that will be deploying products that are based on those specs
involved, is also extremely important.   And, having people that understand
real user experience (and not how things work from an engineer's view) is
also important.  And, of course, the work I do is generally at a higher
layer than your own, so that is why my view is slightly different than
yours.  And, honestly, I think appreciating that there can be two different
views of a situation, with both being equally valid, that is not something
IETFers do very well at all.   [/MB]

> *From:* Mary Barnes <[email-masked]>
> *Sent:* Tuesday, February 23, 2021 11:26 PM
> *To:* Brian E Carpenter <[email-masked]>
> *Cc:* Hannes Tschofenig <[email-masked]>; Fernando Gont <
> [email-masked]>; [email-masked]; GENDISPATCH List <
> *Subject:* Re: [Gendispatch] Diversity and Inclusiveness in the IETF
>
>
>
> Hannes,
>
>
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 24 Feb 2021 08:37:34 -0800

On 2/24/2021 1:39 AM, Vittorio Bertola wrote:
>> The culture of hands-on work needs to be more than a responsibility 
>> of the document authors. It is a culture that has to cut across the 
>> organization, from working group chairs to the IESG. Currently, there 
>> are disincentives to work on code as a document author.
>>
>> I want people with hands-on experience in the leadership of an 
>> engineering organization. For me this is a form of diversity.
>>
> The question is whether you *only* (mostly) want coders in the 
> leadership, or whether you *also* want coders in the leadership. This 
> makes a lot of difference in evaluating your position.

Vittorio,

The word "coder" is a somewhat insulting way to refer to software 
developers. Please stop. This vocabulary implies a hierarchy in which 
the specifications are developed by superior specification writers, then 
handed down to subservient "coders" who merely translate it into 
computer code. This is a very reductive way of considering software 
development. For example, it completely discards the interaction between 
implementation, deployment, testing, and user feedback. In the IETF, the 
writing of good specifications has always benefited from such 
interactions, and we want that to continue.

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Feb 2021 13:38:39 -0300

Hello, Vittorio,

Thanks a lot for your comments! In-line...

On 23/2/21 12:07, Vittorio Bertola wrote:
[,,,]
> 
> Thanks for starting this. I also wanted to write something, but could
> not find the time. I wanted to work on a description of factors and
> dimensions that could make people feel out of place in an
> organization, both in professional and social terms, or make it
> harder to participate. I think that the right approach is first to
> document all the potential issues, and then to discuss whether each
> of them can and should be addressed (in some cases, there might even
> be groups that you do not want to include, but that's a separate
> discussion from documenting that they exist).

Agreed. While our document has some side-note possible suggestions 
(i.e., "this is very doable"), the focus of the document -- at least so 
far -- is in the problem statement, rather than solutions.  SOlutions 
would most likely require their own documents.

[....]
> I only got as far as writing down a bullet list of points, so I'm
> sharing it - you covered part of it already, not everything. I'll be
> happy to contribute text if I have time, but in the meantime, here it
> is:
[...]

The list you've provided is really good. Thanks!

We'll start incorporating all the items you've suggested such that they 
make it into -01.  If you have further thoughts or text, they will be 
very welcome. And, in any case, we'll send a heads-up to the up-coming 
rev (before posting) such that you can verify if there's anything we've 
misunderstood or got wrong.

Thanks a lot!

Regards,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 24 Feb 2021 12:14:05 -0500

On Wed, Feb 24, 2021 at 11:37 AM Christian Huitema <[email-masked]>
wrote:

> Il 24/02/2021 08:22 Hannes Tschofenig <[email-masked]>
> <[email-masked]> ha scritto:
>
> The question is whether you *only* (mostly) want coders in the leadership,
> or whether you *also* want coders in the leadership. This makes a lot of
> difference in evaluating your position.
>
> Vittorio,
>
> developers. Please stop. This vocabulary implies a hierarchy in which the
> specifications are developed by superior specification writers, then handed
> down to subservient "coders" who merely translate it into computer code.
> This is a very reductive way of considering software development. For
> example, it completely discards the interaction between implementation,
> deployment, testing, and user feedback. In the IETF, the writing of good
> specifications has always benefited from such interactions, and we want
> that to continue.
>
+1

I don't write much protocol code, I write synthesizers that write the code
for me. I try to work at the highest level of abstraction possible.

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 24 Feb 2021 18:47:18 +0100 (CET)

>     Il 24/02/2021 17:37 Christian Huitema <[email-masked]> ha scritto:
> 
>     Vittorio,
> 
>     The word "coder" is a somewhat insulting way to refer to software developers. Please stop. This vocabulary implies a hierarchy in which the specifications are developed by superior specification writers, then handed down to subservient "coders" who merely translate it into computer code. This is a very reductive way of considering software development. For example, it completely discards the interaction between implementation, deployment, testing, and user feedback. In the IETF, the writing of good specifications has always benefited from such interactions, and we want that to continue.
> 
Of course (originally being a software writer myself, and still doing it as a hobby) this was not my intention, and personally I never heard any software developer complaining that "coder" is an insulting term. But if it is, I apologize for using it, and we should just add it to the list of problematic words, so that everyone is aware that it should not be used at the IETF.

Then, I also suggest that the list is handed out to every new subscriber of any IETF mailing list, because this is not the first time that I use a perfectly normal term in my native language / environment and I find someone jumping up and taking the issue as an offense (the last time was with the term "militant", when chatting on this same issue).

As a result, I am feeling like I should just stop participating in these discussions for fear of using the wrong choice of language and getting publicly shamed (and in my own culture, like in the Far East, in Arab cultures and elsewhere, "saving your face" in public is paramount). So, ironically, language correctness leads to self-censorship and exclusion.

Now, while we are at it, I also note that sometimes there are extremely offensive terms in my culture that are being commonly used in this discussion. The main example is "race"; in Italy, in Germany(*) and in other European cultures, using the term "race" to refer to a subset of mankind, implying that more than one "human race" exists, or suggesting that there are "race issues" and "race diversities" to be considered, is considered outright racism. I was shocked the first time I saw the term used as a category, but then I realized that there was no intention to offend - just a different linguistic background - and I moved on.

But if the principle is that nobody's sensitivity has to be offended, I think that we should definitely stop using the term "race" in this conversation or anywhere at the IETF.

(*) e.g. see https://www.dw.com/en/dont-use-the-term-race-german-scientists-urge/a-50390582

--

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Feb 2021 15:05:48 -0300

On 24/2/21 14:47, Vittorio Bertola wrote:
>> the specifications are developed by superior specification writers, 
>> then handed down to subservient "coders" who merely translate it into 
>> development. For example, it completely discards the interaction 
>> between implementation, deployment, testing, and user feedback. In the 
>> IETF, the writing of good specifications has always benefited from 
>> such interactions, and we want that to continue.
>>
> Of course (originally being a software writer myself, and still doing it 
> as a hobby) this was not my intention, and personally I never heard any 
> software developer complaining that "coder" is an insulting term. But if 
> it is, I apologize for using it, and we should just add it to the list 
> of problematic words, so that everyone is aware that it should not be 
> used at the IETF.

I'd ask that participants be aware that a number of us speak English as 
a second language. So, while at times we might be aware that for some 
there might be differences (at times subtle) in the meaning of such 
words, other times we're not simply aware about them, or may overlook 
them (since English is not our native language).

For instance, the word "coder" has no equivalent in Spanish (the 
equivalent would be "codificador", but you'd never use that for coder or 
programmer). So it shouldn't come as a surprise that a Spanish-speaking 
person uses "programmer" to refer to "coder", "software developer" or 
"programmer" (itself), or that somehow mixes up these words.

The same probably applies to other languages.

I guess following Postel's advice might be of use here.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Feb 2021 15:23:42 -0300

Hello, Vittorio,

> Then, I also suggest that the list is handed out to every new subscriber 
> of any IETF mailing list, because this is not the first time that I use 
> a perfectly normal term in my native language / environment and I find 
> someone jumping up and taking the issue as an offense (the last time was 
> with the term "militant", when chatting on this same issue).

I couldn't agree more with you.

Just to provide yet another example, last year it was argued on this 
list what greeting with "cheers" (as o¡in "bye") could also result 
offensive -- when I had always assumed that it was simply an informal 
and polite way of saying "bye".

> As a result, I am feeling like I should just stop participating in these 
> discussions for fear of using the wrong choice of language and getting 
> publicly shamed (and in my own culture, like in the Far East, in Arab 
> cultures and elsewhere, "saving your face" in public is paramount). So, 
> ironically, language correctness leads to self-censorship and exclusion.

Isn't there an implicit irony in expecting people from completely 
different cultures and origins, who do not speak the language natively, 
to speak their one's own language in a flawless manner, in the name of 
inclusiveness and diversity?

The fact that people pick one language (out of many, regardless of how 
prominent or widespread it may be), remove a few words, and dare to call 
it "inclusive language", in a way, still amuses me.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Feb 2021 15:51:23 -0300

> 
> Now, while we are at it, I also note that sometimes there are extremely 
> offensive terms in my culture that are being commonly used in this 
> discussion. The main example is "race"; in Italy, in Germany(*) and in 
> other European cultures, using the term "race" to refer to a subset of 
> mankind, implying that more than one "human race" exists, or suggesting 
> that there are "race issues" and "race diversities" to be considered, is 
> considered outright racism. I was shocked the first time I saw the term 
> used as a category, but then I realized that there was no intention to 
> offend - just a different linguistic background - and I moved on.
> 
> But if the principle is that nobody's sensitivity has to be offended, I 
> think that we should definitely stop using the term "race" in this 
> conversation or anywhere at the IETF.

As noted, it seems to me that a lot of the discussion around language is 
how a specific group feels about a specific set of words, because of 
their own historical background...where the rest needs to learn about 
those cultural issues and adapt accordingly (probably without the same 
policy necessarily applying the other way around).

I should also note that, if people are also concerned about historical 
background of words, I'm sure they should also be concerned about 
anything that contains a national symbol/flag or religious symbol (*).
And in that light, there should also be a recommendation in that respect.

(*) e.g., a simple rosary would be deemed as completely harmless in my 
place (I do wear one, although it's not visible),  but it may certainly 
come across quite differently to e.g. people in some parts of Bosnia or 
Belfast (for obvious reasons... which I do understand... and which you 
don't need to go back a long time in history to understand).

Inclusiveness and diversity seem to be way more complex than what some 
seem to imply, and it implies a lot more than cherry-picking on specific 
items that would make a group look "nice and following the trend".

Thanks,

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Feb 2021 20:05:08 -0500

> I understand the interest in quantification, and it might be useful in some cases, but I would like to underline that not everything is quantifiable in a meaningful way.

+1.  thanks.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 25 Feb 2021 14:20:19 +1100

> running code that actually helped improve the specification. We were doing

It's a very interesting comment, about 'not enough people writing the
code'. Since I've joined the IETF I've been hearing people complaining
about 'not enough operators here, where are they?'
I'm a network engineer who has to deal with routers and switches
running vendor's code and with endpoints running various OSes.
So while I have some ideas of what improvements I need from a given
protocol, I'd not be writing actual implementations, because I have no
places to actually run it in the production.
I'd rather collaborate with people who can write that code much faster
and better than I would ever be able so I can run their code in
production and provide some feedback from my operational experience.

> code, we are also coming up with work that does not require any code at all.

Well, plenty of work in the Ops area is like that but I do not think
it's a bad thing necessary.
Are you saying we shouldn't be documenting best (and worst) practices?
-- 
SY, Jen Linkova aka Furry

---

From: Theresa Enghardt <[email-masked]>
Date: Wed, 24 Feb 2021 19:59:59 -0800

Hi Fernando, Keith,

> https://www.ietf.org/archive/id/draft-gont-diversity-analysis-00.txt

Thank you for this document.

One perspective that I missed in this document is academia, as I have 
participated in the IETF as an academic for a few years.

The document mentions "Universities" as an example of organizations for 
which IETF participation might not [be] attractive or feasible. I'm not 
sure I agree.

Some benefits of participating in the IETF for researchers, PhD 
students, etc, potentially to be added to Section 4 as a separate group, 
include:

- Getting feedback on your work, e.g., assumptions you may be making, 
things you may have overlooked, direction for future work
- Input for your own teaching (learning about the IETF and its processes 
has very much enhanced discussions with my students)
- Making industry connections, e.g., for joint projects
- Professional networking, career advancement

When it comes to attending IETF meetings, I think it's worth mentioning 
that they are sometimes co-located with ANRW, an academic workshop, and 
that a lot of IRTF meetings are taking place during the same week. Also, 
there are efforts in the IRTF, such as the IRTF research prize, which 
may help PhD students get an ROI for their IETF-related work, feedback, 
and the opportunity to attend an IETF meeting.

Of course, a lot of the same structural problems that the draft mentions 
still apply to academics, and not all universities are "equal" (e.g., 
big/famous ones probably often have an easier time sending people than 
smaller ones).

One specific example would be Economic Constraints, Section 9: 
Universities usually have a travel budget and they may also have rules 
on how much a hotel is allowed to cost per night. IETF hotels are 
usually, if not always, outside of that budget, and overflow hotels are, 
too. I've usually managed to find something in adequate distance, but it 
did feel a bit strange to be basically excluded from the "official" hotels.

That's just my initial thoughts, and feel free to include them in the draft.

Best,
Theresa

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 01:35:51 -0300

Hello, Theresa,

On 25/2/21 00:59, Theresa Enghardt wrote:
[....]
> - Professional networking, career advancement

Probably part of the issue here is that our I-D talks about 
"participation", where we probably meant something along the lines of 
"active participation" or "making contributions to the IETF" -- e.g., 
reviewing documents, submitting Internet-Drafts, etc.

What you describe does indeed seem beneficial, but in principle doesn't 
seem to necessarily contribute to the work of the IETF.

   -- but please do correct me if I'm missing something or 
miss-interpreting what you're saying...

> and the opportunity to attend an IETF meeting.

We should certainly incorporate something along these lines -- I'll come 
back to you once we have crafted text along this lines. (of course, if 
you have specific text that you'd like to suggest, please do let us know!)

FWIW, what you note is one of the motivations/arguments for e.g. 
introducing f2f meeting fee waivers -- since in such cases there could 
be people that might be able to attend the meeting (space/time-wise), 
but might not be able to do it as a result of the meeting fees. IIRC, 
netdev was also hosted next to the IETF meeting in the past.

[...]
> too.

I couldn't agree more. In fact, from our perspective this was actually 
assumed (!)... but we should definitely spell this out.  (the same 
probably also applies to the list of "recommended restaurants" that 
somehow circulate in the attendee mailing-lists, as well as some 
interesting 90USD+/meal dinners that get organized during the week).

> I've usually managed to find something in adequate distance, but it 

Believe me that I know exactly what you mean. :-)

Thanks a lot!

Regards,

---

From: Dan Harkins <[email-masked]>
Date: Wed, 24 Feb 2021 21:22:53 -0800

> Are you saying we shouldn't be documenting best (and worst) practices?
   Huh?

   I don't believe I have ever said that and I don't believe I have
ever said anything even close to that.

   Dan.

---

From: Theresa Enghardt <[email-masked]>
Date: Wed, 24 Feb 2021 21:56:30 -0800

Hi Fernando,

See inline:

On 24.02.21 20:35, Fernando Gont wrote:
>> […]
>> students, etc, potentially to be added to Section 4 as a separate
>> group, include:
>>
>> - Input for your own teaching (learning about the IETF and its
>> processes has very much enhanced discussions with my students)
> What you describe does indeed seem beneficial, but in principle
> doesn't seem to necessarily contribute to the work of the IETF.
>

I was talking about active participation, too.

For example, if a researcher goes and presents their work at an IETF
Working Group meeting, I would consider that an IETF contribution, e.g.,
that the Working Group can get ideas from. For instance, a few years
ago, we have had several academics present their work in TAPS, and that
was definitely a lot of helpful input. Not sure how common this style of
contribution is, but I think it does happen especially when a smaller WG
is in an "early stage" where they benefit from a lot of input and ideas.
(Of course, a lot of work that is relevant to IETF Working Groups is
getting presented at IRTF sessions, e.g., MAPRG, IRTF Open, or at ANRW.
But I can understand if you consider these out of scope for your document.)

Another way for academics to contribute is to implement (part of) a
draft as an academic exercise, or have a student implement it as a
project, and then give feedback to the Working Group. We have had
multiple such implementations in TAPS. Even if the implementation is
most likely not going to be widely deployed, and even if development may
not continue beyond the duration of a project, it is still helpful input
for the Working Group. And for the academic, it gives the implementer a
relevant and interesting project to work on, the implementer gets some
experience with IETF technology, and they get to make professional
connections, which can result in further collaboration. Definitely a
win-win, and something that I've seen happen at IETF hackathons.

Moreover, academics may submit an idea as an Internet Draft just to get
feedback on it. Even if maybe the draft will not make it all the way to
an RFC, or some parts of the original draft may be taken out and become
part of a different draft, etc, it can be a very valuable perspective
for the academic. Again, I have seen this happen in TAPS.

Finally, I liked reviewing drafts even as an academic, because it helped
me understand current work better, which, again, may provide context and
input for future research.

Perhaps as an additional perspective, at ANRW 2018, Sharon Goldberg gave
a brief presentation on why and how academics may want to participate in
the IETF, see the first 10-15 minutes of this recording:
https://www.youtube.com/watch?v=gSvZcMAcC_0

> […]

Yes, definitely. Now maybe it would also be interesting to consider if
the demographics of participants in the IRTF or in Netdev are
substantially different from the participants in the IETF.

>> Universities usually have a travel budget and they may also have
>> rules on how much a hotel is allowed to cost per night. IETF hotels
>> are usually, if not always, outside of that budget, and overflow
>> hotels are, too.
>

Agreed. I think it's a good idea to mention that the meeting fee is not
the only economic barrier to participation, but often, flight and hotel
are much more expensive. (Especially for students, for whom the meeting
fee is reduced.)

Best,
Theresa

---

From: Christian Huitema <[email-masked]>
Date: Wed, 24 Feb 2021 22:01:50 -0800

> win-win, and something that I've seen happen at IETF hackathons.

Yes, there are many ways academics can contribute. Look for example at 
the work Robin Marx did on structured QUIC logs formats and 
visualization tools. Part of his PhD, but also a very valuable 
contribution to the working group, with many implementation 
standardizing on the log format that he proposed and running his tools. 
That was great.

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 03:13:19 -0300

Hi, Theresa,

On 25/2/21 02:56, Theresa Enghardt wrote:
[...]
> I was talking about active participation, too.

Oops, my bad. Thanks for the clarification!

> Working Group meeting, I would consider that an IETF contribution, e.g.,

Indeed it is. I thought you were implying meeting attendance, without 
necessarily contributing. -- my bad.

> But I can understand if you consider these out of scope for your document.)

I think what you describe is definitely within scope.

That said, in my experienve, in many cases groups seem to receive points 
for peer-reviewed conference papers, but not for IRTF/IETF-style of 
participation, unfortunately. So making it to the IETF will typically be 
harder (in terms of funding) than e.g. attending to an IEEE or ACM 
conference.

[...]

This is all indeed very valid. I'll do my best to come up with text to 
incorporate this into our document (thanks, btw!).

[....]
> substantially different from the participants in the IETF.

I'll check to see if there are any stats available for those.

> are much more expensive. (Especially for students, for whom the meeting

Will try to spell these things out more clearly in the next rev.

Thanks a lot for your comments!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 03:17:05 -0300

Hi, Christian,

> standardizing on the log format that he proposed and running his tools. 

FWIW, for the most part we were implying the extent to which Academia 
might e.g. fund participation. We'll certainly expand on this topic, 
since the discussion regarding Academia is certainly incomplete/inaccurate.

Thanks,

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 25 Feb 2021 08:15:10 +0000

Hi Jen,

> So while I have some ideas of what improvements I need from a given protocol, I'd not be writing actual implementations, because I have no places to actually run it in the production.
> I'd rather collaborate with people who can write that code much faster and better than I would ever be able so I can run their code in production and provide some feedback from my operational experience.

It is important in this discussion to distinguish a couple of things.

- First, there is prototyping software that helps to provide input while writing the specification. Ideas that look great on paper may not necessarily work well when implemented.
- Second, not everyone in the working group is likely to implement a given protocol. However, someone has do the work. If we write specifications without any implementation input then the quality will be lower.

I am arguing that at least the authors of documents should have enough incentives to prototype their own specs. The leadership can help to create a culture in the IETF where implementation work is valued.

So, if you are an author of a protocol spec then you should IMHO also verify the spec via an implementation.

There are lots of specifications that do not describe protocols and hence they may not need any implementation work. They will benefit from different input, as some of the other folks on this list have pointed out. This may, for example, be operational know-how to configure already implemented protocols and to make observations with the installed base. This is an important area, as Henning Schulzrinne pointed out in his paper "Networking Research - A Reflection in the Middle Years", see https://arxiv.org/abs/1809.00623.

I hope this clarifies my statements.

Let's look at an example. The drafts you are involved in*, such as draft-ietf-6man-grand-03, look like protocol specifications to me (although I am not participating in 6man). If you care enough about draft-ietf-6man-grand, which I am assuming since you the sole author,  you might want to check whether the content is actually sound. This can happen in various ways, such as by doing a prototype or by testing configurations (if that's appropriate).

Ciao
Hannes

*: I hope I searched correctly.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Theresa Enghardt <[email-masked]>
Date: Thu, 25 Feb 2021 08:16:16 -0800

Hi Fernando,

On 2/24/21 10:13 PM, Fernando Gont wrote:
> That said, in my experienve, in many cases groups seem to receive 
> points for peer-reviewed conference papers, but not for 
> IRTF/IETF-style of participation, unfortunately. So making it to the 
> IETF will typically be harder (in terms of funding) than e.g. 
> attending to an IEEE or ACM conference.

That is true. With ANRW, you at least get to present a short paper or 
poster at a workshop, so that's a step in the right direction.

Good point about publications. RFCs are publications, too, so there is 
definitely some ROI in (co-)authoring an RFC as an academic. However, 
usually the entire process takes much longer than writing academic 
papers. And I'm not sure how academia at large values RFCs relative to 
papers, but at least in the part that I know, I would say they're valued.

I think some academic institutions explicitly value it if researchers 
give "input to practice", demonstrate the applicability of their work, 
etc. So that could be used as a reason for presenting at IETF meetings, 
too, though most academic institutions would not understand the 
difference between IETF and IRTF sessions.

You're welcome and good luck with the next revision!

Best,
Theresa

---

From: Andrew Campling <[email-masked]>
Date: Thu, 25 Feb 2021 17:21:10 +0000

> The word "coder" is a somewhat insulting way to refer to software developers. Please stop. This vocabulary implies a hierarchy in which the specifications are developed by superior specification wr…

In previous discussions on this list, others highlighted the importance of assuming the good intentions of contributors and also of making allowances for possible differences in meaning between languages and cultures.  I think that the above text inadvertently demonstrates the problems that can otherwise arise. (For the record, I started my working life as a professional programmer, am a native UK English speaker and do not see any reason to be offended by the use of the term ”coder”, noting that it might be regarded by some as a little idiosyncratic in this context but nothing more).

I’d be concerned that someone who is not confident in their use of English could easily be discouraged from further contributions upon receiving such a negative response to a pretty innocuous use of language, or even in observing such a reaction to another person’s post.  If diversity is to be encouraged then a more forgiving approach is needed, especially from those in or having previously occupied leadership positions.

Separately, I hope that the proposed activity on terminology does not become a dumping group for the preferences and dislikes of individuals, otherwise we will quickly discover that some of us are easily offended.  Let’s instead focus on providing positive guidance on good choices of terminology, ensuring that any examples of words or phrases to be discouraged is kept as small as possible, with robust references to justify inclusion.  In addition, I’d encourage checks to ensure that any such list has input from as diverse a spread of nationalities and cultures as possible - a document that primarily focuses on the feelings of one cultural group or nationality is likely to reinforce views that the IETF is not a diverse organisation.

Andrew

---

From: Lars Eggert <[email-masked]>
Date: Thu, 25 Feb 2021 19:29:48 +0200

Hi,

On 2021-2-25, at 18:16, Theresa Enghardt <[email-masked]> wrote:
> That is true. With ANRW, you at least get to present a short paper or poster at a workshop, so that's a step in the right direction.

that was actually the main motivation for collocating ANRW always with the IETF - typically, academics can justify conference and workshop travel much more easily than standards travel.

> Good point about publications. RFCs are publications, too, so there is definitely some ROI in (co-)authoring an RFC as an academic. However, usually the entire process takes much longer than writing academic papers. And I'm not sure how academia at large values RFCs relative to papers, but at least in the part that I know, I would say they're valued.

One thing we did to increase the value of RFCs to academics was to assign them DOIs, which at least for universities in some geos is a prerequisite to even recognizing RFCs as academic output.

Thanks,
Lars

---

From: Andrew Campling <[email-masked]>
Date: Thu, 25 Feb 2021 17:39:28 +0000

>> for the first time the tools are a relic of 1990 of thereabouts and 
>> can be confusing and difficult.

+1 

> FWIW, we have already started to work on a revision of the draft (working copy at: 

This made me smile as GitHub is itself an excellent example of a tool being a barrier to entry for new participants.  I've been using word processors since the early '80s (WordStar back in the day), don't understand why anyone would opt to use a different tool to write a document.  I know that this point of view will not be accepted by many current IETF participants but it seems particularly perverse to use a software development tool to write documents when there are many widely available options that are far better suited to the task (many of which support collaborative writing).  

If the intent is to broaden participation by people from different disciplines then I'd urge the use of more commonly used tools wherever possible.  

Andrew

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 25 Feb 2021 17:58:52 +0000

> In previous discussions on this list, others highlighted the importance of assuming the good intentions of contributors and also of making allowances for possible differences in meaning between lan…

<bhs> I'll add to this and say that I volunteer regularly with a non-profit called "Girls Who Code". Nobody associated with this org sees anything pejorative about saying someone can "code".</bhs>

> Separately, I hope that the proposed activity on terminology does not become a dumping group for the preferences and dislikes of individuals, otherwise we will quickly discover that some of us are…

<bhs> I mostly agree. Both this discussion and previous (on the ietf list many months ago) opinion that the words "folks" and "y'all" are offensive to some people suggest that it's important to be able to reference multiple sources that show a real problem with a term. It's not enough for a single person to claim offense. The main problem that I, personally, see driving a need for the TERM WG is that many companies (mostly from one region) have told their employees not to use certain terms in any document or code they are associated with. Given the momentum of this movement and speed at which it is spreading to many of the companies employing IETF participants, if IETF does not address the problem ASAP, this could make it difficult for employees of these companies to actively participate. This will primarily impact a specific region/country and people employed by large companies in that region and would be independent of the race, culture, or gender of the participants. Which suggests 2 points:
=> The first problem TERM (and IETF) is tackling will ensure people employed by numerous large US companies can continue to fully participate in IETF. It may or may not have any impact on removing possible barriers to certain people based on race, gender, or culture; anyone who thinks it will have no impact on these barriers is welcome to ignore that as a reason and focus on the potential impact to participation by employees of large US companies.
=> Even if the problem with use of a specific term is limited to a single region/country...  if the problem is sufficiently widespread in that one country and could impact the ability of people from that country to participate in IETF, it should still be fair game.

Barbara </bhs>

---

From: Andrew Campling <[email-masked]>
Date: Thu, 25 Feb 2021 18:28:10 +0000

On 2/25/2021 17:59, STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>  wrote:

This is, IMHO, a very helpful insight, I’ve not heard it expressed this way previously.  If the primary motivation of some for addressing “problem” terminology is to address policy decisions by large US companies that may impair the ability of their employees to participate in the IETF then that needs to be acknowledged, otherwise there is a risk of effort being wasted to solve the wrong problem or only partially solving this one.  I don’t believe that the discussion has previously reflected this understanding of the underlying task if it is, in reality, to satisfy US corporate sensitivities* rather than deal with issues of diversity and inclusiveness, noting that these may benefit too.

I’d imagine that being able to reference some of the specific policies of the companies in question would be particularly helpful in this regard.

Andrew

* NB There is no intention to downplay these nor suggest that they do not reflect the concerns of employees or other stakeholders.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 14:54:32 -0300

On 25/2/21 14:39, Andrew Campling wrote:
[...]
[....]
>
>   > This made me smile as GitHub is itself an excellent example of a
> tool being a barrier to entry for new participants.

Note: I'm using github just as a file repository. I don't request or
expect people to create an account, or send pull requests. And where
certainly *not* using github as an issue tracker.

 > I've been using word processors since the early '80s (WordStar back in
 > the day), don't understand why anyone would opt to use a different
 > tool to write a document.  I know that this point of view will not be
 > accepted by many current IETF participants but it seems particularly
 > perverse to use a software development tool to write documents when
 > there are many widely available options that are far better suited to
 > the task (many of which support collaborative writing).

FWIW, we're editing the xml source with simple text editors (Linux gedit 
in my case), and then processing it with the xml2rfc tool.

So far, we're bouncing the text among co-authors, changes are applied, 
and then git is essentially used as a simple e.g. ftp alternative -- 
that's it.

And, since you've raised it: I personally agree that requiring the use 
of git/github does represent yet another barrier.

> If the intent is to broaden participation by people from different 
> disciplines then I'd urge the use of more commonly used tools 
> wherever possible.

I might as well upload the document via ftp/sftp, and subsequently 
provide an URL. git/gihub was simply easier.

But in no way we require or even expect the reader to use git/github.
(I do understand that other folks or wgs do... but that's not the case 
for this document).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 15:00:42 -0300

> that was actually the main motivation for collocating ANRW always with the IETF - typically, academics can justify conference and workshop travel much more easily than standards travel.

That's certainly interesting. We'll add a note about this along with 
Theresa's other comments.

> One thing we did to increase the value of RFCs to academics was to assign them DOIs, which at least for universities in some geos is a prerequisite to even recognizing RFCs as academic output.

Was the rationale documented anywhere?  (since this might be of value to 
note/reference, along with your other note above).

Thanks!

Regards,

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 25 Feb 2021 19:24:49 +0000

Nothing requires anyone to use Git or GitHub.

On the other hand, many (millions) of people do, people who often write open source code, and we want to engage with that community. As seems common for the IETF, it's up to the WG to decide.

---

From: Niels ten Oever <[email-masked]>
Date: Thu, 25 Feb 2021 20:32:38 +0100

On 25-02-2021 19:00, Fernando Gont wrote:
> That's certainly interesting. We'll add a note about this along with Theresa's other comments.
> 
> 
> 
> 
> Was the rationale documented anywhere?  (since this might be of value to note/reference, along with your other note above).

This piece is also relevant in this discussion: http://www.sigcomm.org/sites/default/files/ccr/papers/2010/January/1672308-1672315.pdf

Best,

Niels

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 16:34:41 -0300

> Nothing requires anyone to use Git or GitHub.

If a WG somewhat requires use of github, then the barrier is there.

> On the other hand, many (millions) of people do, people who often
> write open source code, and we want to engage with that community. 

My take is that engaging the open source community has more to do with 
lowering the barrier (including the economic barrier), and taking their 
input seriously, than with crafting documents with the tools said 
community usually employs when crafting code.

Similarly, to the extent that has been possible, I've tried to engage 
them asking for specific questions or trying to produce patches for 
their projects -- which tends to work better in terms of engaging them 
than "please look at my draft/spec... it's on gihub, btw".

Just my two cents,

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 25 Feb 2021 19:48:52 +0000

>    If a WG somewhat requires use of github, then the barrier is there.

Since no person, or no WG, has infinite resources, almost any attempts to engage some people mean that some others feel left out.  (Note the almost)

The IETF still maintains that no matter how git/GitHub are used, the classic mechanisms of email, etc., still must be used. Does that mean some conversations aren't fully discussed on the email, and some people feel left out? Yes.  Some people also dislike MIME email, and the moving away from IPv4 and FTP.  Things change.  For myself, I am just glad that we're not commenting on things via SMS.  I am tempted to create an OnlyFans account for ACME or HTTPAPI, tho. :)

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 17:09:43 -0300

On 25/2/21 16:48, Salz, Rich wrote:
> Since no person, or no WG, has infinite resources, almost any
> attempts to engage some people mean that some others feel left out.
> (Note the almost)

Why do you think git/github will engage somebody that would otherwise 
not be engaged?

> The IETF still maintains that no matter how git/GitHub are used, the
> classic mechanisms of email, etc., still must be used.

When discussions end up spread over gihub and email lists, that's not a 
nice feature, IMO.

> Does that mean
> some conversations aren't fully discussed on the email, and some
> people feel left out? Yes.  Some people also dislike MIME email,

I use the least common denominator: plain text email.

Still most email clients will mangle patches sent via email -- which 
happens to be the normal workflow some projects such as the linux kernel 
and openbsd -- so at least for those things you'll probably resort to 
mutt or the like.

> and
> the moving away from IPv4 and FTP.  Things change.  For myself, I am
> just glad that we're not commenting on things via SMS.  I am tempted
> to create an OnlyFans account for ACME or HTTPAPI, tho. :)

My take is: if the tool improves your workflow, go for it. If it will 
get in the way, don't.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 25 Feb 2021 20:17:55 +0000

not be engaged?

Don't know for sure.  Have some guesses.  But that doesn't seem productive (like the OAUTH threads).

    get in the way, don't.

And my point is that improvement for some is bad for others and that's the way things are.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 25 Feb 2021 12:26:44 -0800

> On the other hand, many (millions) of people do, people who often write open source code, and we want to engage with that community. As seems common for the IETF, it's up to the WG to decide.

Really, we engaged with the open source community by starting using GitHub?

What I saw is the opposite:  Open source developers were already working with the IETF, and some of them shoved GitHub down our throats.  This is not the IETF trying to be inclusive, this is developers trying to tell us how to do our job.

And yes, I am a coder and git and vim is where I spend most of my professional time.

-- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 17:30:55 -0300

On 25/2/21 17:17, Salz, Rich wrote:
> Don't know for sure.  Have some guesses.  

This is not the first "proposal" associated with diversity (in this 
case, engagin open source developers) with not much of a rationale 
behind it :-) , so to speak...

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 25 Feb 2021 20:40:19 +0000

The rationale is that there are millions of people using GitHub, and if do documents with their toolchain, we will get more feedback from developers than if we tried to draw them into our toolchain.  I didn't realize that was what you were asking me.  This rationale was stated multiple times in the GIT WG.

Marc:
> What I saw is the opposite:  Open source developers were already working with the IETF, and some of them shoved GitHub down our throats. 

Interesting viewpoint.  Did you attend any of the WG meetings?  I didn't see your name in the mailing list archives.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 25 Feb 2021 12:45:43 -0800

> Interesting viewpoint.  Did you attend any of the WG meetings?  I didn't see your name in the mailing list archives.

Of the gendispatch WG meetings?  No.  I was responding to the email in ietf@

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Feb 2021 12:49:49 -0800

On Thu, Feb 25, 2021 at 12:40 PM Salz, Rich <rsalz=
[email-masked]> wrote:

> The rationale is that there are millions of people using GitHub, and if do
> documents with their toolchain, we will get more feedback from developers
> than if we tried to draw them into our toolchain.  I didn't realize that
> was what you were asking me.  This rationale was stated multiple times in
> the GIT WG.
>

FWIW, my impression of the situation is the same as Rich's. I can say with
confidence that when TLS decided to adopt Github it was because we had seen
that it worked well in H2. With that said, I do think it made it easier for
people to get involved, in part because it was easy to offer small changes
without subscribing to a list, etc. It certainly made it easier to accept
such contributions.

-Ekr

> Marc:
> > What I saw is the opposite:  Open source developers were already working
> with the IETF, and some of them shoved GitHub down our throats.
>
> Interesting viewpoint.  Did you attend any of the WG meetings?  I didn't
> see your name in the mailing list archives.
>
>
> --
> Gendispatch mailing list
> [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Thu, 25 Feb 2021 16:06:05 -0500

On 2/25/21 12:58 PM, STARK, BARBARA H wrote:

> The main problem that I, personally, see driving a need for the TERM WG is that many companies (mostly from one region) have told their employees not to use certain terms in any document or code they are associated with. Given the momentum of this movement and speed at which it is spreading to many of the companies employing IETF participants, if IETF does not address the problem ASAP, this could make it difficult for employees of these companies to actively participate. This will primarily impact a specific region/country and people employed by large companies in that region and would be independent of the race, culture, or gender of the participants.

I'm not following this.   Are you saying that IETF will be expected to 
bring its notion of acceptable vocabulary in line with those of some 
large companies that are mostly from one region so that those companies' 
employees are not at risk of violating their employers' policies if they 
participate in IETF?   Or are you saying that document authors/editors 
who work for such companies will be constrained by IETF to violate their 
employers' policies if IETF doesn't adopt its own policy (which might be 
different from the policies of those companies)?

Given that we're all supposed to be participating in IETF as 
individuals, do those companies also constrain what their employees can 
write on their own time?

I guess I don't see a TERM document forcing anyone to use any particular 
terminology (at least, I hope it doesn't) so much as saying "try to 
avoid these specific terms unless there's a good reason to do so".   And 
that seems Mostly Harmless to me and may create some good will.   But 
if  IETF has to align its rules with those of Big Companies Mostly From 
One Region, I consider that extremely problematic.

Keith

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 18:16:44 -0300

On 25/2/21 17:49, Eric Rescorla wrote:
[...]
>     The rationale is that there are millions of people using GitHub, and
>     if do documents with their toolchain, we will get more feedback from
>     developers than if we tried to draw them into our toolchain.  I
>     didn't realize that was what you were asking me.  This rationale was
>     stated multiple times in the GIT WG.
> 
> FWIW, my impression of the situation is the same as Rich's.

Using the same toolchain, per se, doesn't seem like a rationale (note, 
I'm *not* challenging whether it was effective in your experience, but 
why rather why it was expected ot make a difference).

> I can say 
> with confidence that when TLS decided to adopt Github it was because we 
> had seen that it worked well in H2. With that said, I do think it made 
> it easier for people to get involved, in part because it was easy to 
> offer small changes without subscribing to a list, etc.

Ok, so this seems to imply that part of the thing is that subcribing to 
the mailing-lists is seen as part of the problem.

What about e.g. the archives for the discussions, for future reference? 
Is github.com expected to take on that role?

> It certainly made it easier to accept such contributions.

Certainly this kind of think may make the life of some easier, and the 
life of others more painful. But there *is* an implied tradeoff here. 
It's not a win-win thing.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Feb 2021 10:21:00 +1300

> One thing we did to increase the value of RFCs to academics was to assign them DOIs, which at least for universities in some geos is a prerequisite to even recognizing RFCs as academic output.

Nevertheless, it is in general hard to get RFCs recognised as valuable for tenure and promotion purposes, compared to more traditional publication streams such as highly-rated journals. That's one reason we did https://dl.acm.org/doi/10.1145/1672308.1672315 but I'm not sure it has had much impact.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Thu, 25 Feb 2021 16:25:54 -0500

[private reply]

On 2/25/21 4:21 PM, Brian E Carpenter wrote:

> Nevertheless, it is in general hard to get RFCs recognised as valuable for tenure and promotion purposes, compared to more traditional publication streams such as highly-rated journals. That's one reason we didhttps://dl.acm.org/doi/10.1145/1672308.1672315  but I'm not sure it has had much impact.

Back when I was a university researcher, one of my rejected grant 
proposals got returned with a note from a reviewer that said "you're 
spending time at the wrong conferences and citing the wrong kinds of 
references".   (Referring to IETF conferences and RFCs.)

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 18:22:09 -0300

On 25/2/21 18:06, Keith Moore wrote:
>> The main problem that I, personally, see driving a need for the TERM 
>> WG is that many companies (mostly from one region) have told their 
>> employees not to use certain terms in any document or code they are 
>> associated with. Given the momentum of this movement and speed at 
>> which it is spreading to many of the companies employing IETF 
>> participants, if IETF does not address the problem ASAP, this could 
>> make it difficult for employees of these companies to actively 
>> participate. This will primarily impact a specific region/country and 
>> people employed by large companies in that region and would be 
>> independent of the race, culture, or gender of the participants.
> 

My next question would be: if folks from X country require e.g. that 
people dress in a certain way (for religious purposes, or whatever), 
since otherwise they wouldn't be able to contribute... what would be the 
IETFs take on this?

Or, let me ask a different question: is the IETF to be taken as a global 
organization?

Thanks,

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Feb 2021 13:35:30 -0800

> why rather why it was expected ot make a difference).

Well, as I said below, for TLS and QUIC we had the experience of HTTP
to draw on, so our expectations were mostly "this will be similar to HTTP".
I can't speak for what caused the HTTP chairs to decide to use GitHub.
Perhaps experience in WHATWG?

> Is github.com expected to take on that role?

Generally yes, though it's of course possible to archive this separately.
Obviously, there are pluses and minuses here, but in my experience
GitHub makes doing the archaeology on what resulted in a given
decision quite a bit easier because you can use 'git blame' and the
commit history to find when the change was introduced and through
that the discussion (i.e., issue/PR) that lead to it.

> It's not a win-win thing.

It's very rare to find a change that doesn't inconvenience someone, and
given that we had a whole WG on this topic, I don't think it's that useful
to relitigate the relative pluses and minuses of Github usage.

-Ekr

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 18:41:45 -0300

On 25/2/21 17:40, Salz, Rich wrote:
 > On 25/2/21 17:26, Marc Petit-Huguenin wrote:
[...]
> Interesting viewpoint.  Did you attend any of the WG meetings?  I didn't see your name in the mailing list archives.

Well, as per this discussion, it seems that mailing-lists and 
mailing-lists archives don't really matter much, anyway  ?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 26 Feb 2021 11:06:37 +1300

> mailing-lists archives don't really matter much, anyway  ?

Not so; have you read RFC8874?

What happens in GitHub stays in GitHub. As far as IETF consensus goes, RFC2148 remains determinant.

   Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 25 Feb 2021 22:25:26 +0000

>    Using the same toolchain, per se, doesn't seem like a rationale

Reducing a barrier to contribute is worthwhile.  Just as some are advocating being able to submit a draft in any format they have on-hand.

No.  Participating in a high-volume list with no practical ability to filter things out to just the one section of a draft, for example.

It is possible.  Martin's tools already archive all issues and discussions, and the IETF is already making copies of those repositories mentioned in the datatracker.

In my experience, very few things are win-win.

It would be nice if all potential IETF participants were born in the same era and used to the same tools, I suppose.  But it would also be very boring.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 19:33:24 -0300

On 25/2/21 19:25, Salz, Rich wrote:
> Reducing a barrier to contribute is worthwhile.  

When you're changing the way of contributing, you're not universally 
"reducing the barrier". -- certainly not for somebody that does't do git.

> Just as some are advocating being able to submit a draft in any format they have on-hand.
> 

Point taken. So... mailing list are seen as a problematic mechanism to 
carry our work?

[...]
F is already making copies of those repositories mentioned in the 
datatracker.
> In my experience, very few things are win-win.

Indeed. That's why claiming that the barriers are lowered is a dificult 
claim.

> It would be nice if all potential IETF participants were born in the same era and used to the same tools, I suppose.  But it would also be very boring.

It's probably also boring that we all use IP....

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 25 Feb 2021 23:49:37 +0000

The IETF has not changed the way people contribute.  Drafts are still posted to the datatracker, mailing lists still exist for feedback and comment (and must be used for confirming consensus, etc).  Just because there are more paths into the datatracker now.  I mean, probably around 1985-1995 we all just FTP'd the documents we wanted to read.  Is anyone going to argue that it's not easier now?

    carry our work?

For some people I think the answer is yes.  It seems that overall use of email is declining, but it's hard to get real numbers without getting tangled up in email marketing newsletter business.  But I feel like you keep trying to have me make blanket assertions and I don't want to do that.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 26 Feb 2021 01:29:56 -0300

Hi, Rich,

On 25/2/21 20:49, Salz, Rich wrote:
> The IETF has not changed the way people contribute.  Drafts are still
> posted to the datatracker, mailing lists still exist for feedback and
> comment (and must be used for confirming consensus, etc).  Just
> because there are more paths into the datatracker now.  I mean,
> probably around 1985-1995 we all just FTP'd the documents we wanted
> to read.  Is anyone going to argue that it's not easier now?

Based on some comments it seems that in some cases a significant 
fraction of the discussion moved to github. Hence my question.
In such a case, participants are kind of required to participate in github.

I didn't participate much (if at all) in the recommendations regarding 
the use of github in the ietf. And my assumtion was that for the most 
part it was more of a "use it if deemed useful", but was assuming the 
discussions that would lead to changes to remain in the mailing-lists.

> For some people I think the answer is yes.  It seems that overall use
> of email is declining, but it's hard to get real numbers without
> getting tangled up in email marketing newsletter business.  But I
> feel like you keep trying to have me make blanket assertions and I
> don't want to do that.

No, no. It was a honest question. Me I wasn't aware about some of the 
assumptions that were mentioned in the thread... hence my questions.

Thanks,

---

From: Lars Eggert <[email-masked]>
Date: Fri, 26 Feb 2021 09:50:43 +0200

Hi,

> Was the rationale documented anywhere?  (since this might be of value to note/reference, along with your other note above).

not as far as I know. This was discussed a bunch of times at various IRSG meetings ~5 years ago. (As as the decision on how to schedule the ANRW.)

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 26 Feb 2021 09:54:49 +0200

Hi,

On 2021-2-25, at 23:21, Brian E Carpenter <[email-masked]> wrote:
> Nevertheless, it is in general hard to get RFCs recognised as valuable for tenure and promotion purposes, compared to more traditional publication streams such as highly-rated journals.

completely agreed. DOIs don't fully solve the problem, they are a first required step. Some tenure committees operate under rules that don't makes it difficult to consider evaluating something that doesn't have a DOI.

> That's one reason we did https://dl.acm.org/doi/10.1145/1672308.1672315 but I'm not sure it has had much impact.

Yes, that is an invaluable document when RFCs are able to be considered for evaluation.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 26 Feb 2021 10:34:32 +0200

> If a WG somewhat requires use of github, then the barrier is there.

It may be a barrier to some. It may also *lower* the barrier for others. It's a tradeoff.

For example: The QUIC WG uses GitHub extensively. That has made it very easy for the engineers that are implementing QUIC stacks at various organizations to participate in the WG, because much of that development already happens on GitHub and so the WG process is more approachable. For many of these engineers, QUIC is their first involvement in the IETF, and using tools and workflows that are familiar hence lowers the bar for their participation. On the flip side, several longtime IETF participants were not very familiar with GitHub and its workflows, and the WG's heavy use of them required some adjustment, making it a bit more challenging for them for a while. Personally, I believe this was a worthwhile tradeoff to make, given that we needed to manage the design of a very complex protocol, but YMMV.

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Fri, 26 Feb 2021 10:38:25 +0200

On 2021-2-25, at 22:09, Fernando Gont <[email-masked]> wrote:
> When discussions end up spread over gihub and email lists, that's not a nice feature, IMO.

It is possible to configure GitHub so that issue discussion is reflected onto a mailing list, and email responses get reflected into the web issue system. QUIC uses the quic-issues@ mailing list for that. That mailing list is an IETF list, searchable and archived.

Thanks,
Lars

---

From: Fernando Gont <[email-masked]>
Date: Fri, 26 Feb 2021 06:09:56 -0300

Hi, Lars,

> It may be a barrier to some. It may also *lower* the barrier for others. It's a tradeoff.

That's essentially what I tried to note.

FWIW, I only had one experience of github usage in an IETF wg, and the 
result wasn't probably the best -- discussion split in to different 
places, some huge monolithic pull requests, and other things. -- of 
course, this doesn't talk about the tool, but rather about how it was 
used.  -- Glad it worked differently for QUIC!

Out of curiosity: has the experience been documented such that e.g. 
other groups could learn/reproduce the adjustments you referred to?

Thanks,

---

From: Lars Eggert <[email-masked]>
Date: Fri, 26 Feb 2021 11:17:10 +0200

On 2021-2-26, at 11:09, Fernando Gont <[email-masked]> wrote:
> Out of curiosity: has the experience been documented such that e.g. other groups could learn/reproduce the adjustments you referred to?

I think RFC8874/8875 capture what we did.

Thanks,
Lars

---

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 26 Feb 2021 21:30:36 +1100

My experience is that a significant fraction of the discussion happens in hallways and bars, some of which I have been at, some not.

The final decisions have always been made on the mailing list though.

Bron

  [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Fri, 26 Feb 2021 11:03:07 +0000

> On 25 Feb 2021, at 16:16, Theresa Enghardt <[email-masked]> wrote:
> 
> Hi Fernando,
> 
>> That said, in my experienve, in many cases groups seem to receive points for peer-reviewed conference papers, but not for IRTF/IETF-style of participation, unfortunately. So making it to the IETF will typically be harder (in terms of funding) than e.g. attending to an IEEE or ACM conference.
> 

I think this is very much country dependent. The UK government, for example, explicitly evaluates impact beyond academia when assessing university research, so promotion committees generally value standards work, but that’s certainly not true everywhere.

Colin

> I think some academic institutions explicitly value it if researchers give "input to practice", demonstrate the applicability of their work, etc. So that could be used as a reason for presenting at IETF meetings, too, though most academic institutions would not understand the difference between IETF and IRTF sessions.
> 

-- 
Colin Perkins
https://csperkins.org/

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 26 Feb 2021 12:56:27 +0100 (CET)

>     Il 25/02/2021 21:49 Eric Rescorla <[email-masked]> ha scritto:
> 
>     I do think it made it easier for people to get involved, in part because it was easy to offer small changes without subscribing to a list, etc. It certainly made it easier to accept such contributions.
> 
My experience is the exact opposite - there were a number of times in which I wanted to propose text for a document, but then I was pointed at Github, and I am not at ease with it and did not have a lot of time for it. So I gave up or, rather than working on actual text, I just replied on the mailing list making my points and suggestions in a more general way. Unfortunately, this makes your points less likely to be included, since the authors would have to make the effort to write the text for you, or, even if you provide text on the mailing list, the effort to copy and turn it into a pull request.

Some do, some don't; and even if they do, you are placed in the difficult position to ask someone else to do "your" job. Even admitting that you may need help with the tools, in this environment, is a bit scary - it's like admitting in public that you are not "good enough" to participate in the IETF. This gets even worse if you know that your contribution is "diverse" enough for you to expect that some of the regular participants will not receive it well.

In the end, as Lars correctly pointed out, this is a tradeoff. There are instruments that are easier to use for some groups but harder for others. There are instruments that work better with certain types of contributions, and other instruments that work better with other types. So, the choice of instruments is not neutral - it can tilt the balance in participation.

It may indeed be that Github is optimal, maximizing contributions from the people that have more to say. It may also be that it is functional to the preservation of the current leadership and culture of the organization, making it difficult for people with other backgrounds to participate effectively. I do not feel expert enough in the IETF to make a judgement on this, but the issue is clearly there.

--

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 26 Feb 2021 13:04:54 +0100

> On Feb 26, 2021, at 12:56 PM, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> There were a number of times in which I wanted to propose text for a document, but then I was pointed at Github

Eh, don’t let the code-monkeys get you down.  If they knew what they were talking about, they’d say it in IRR poem records.  :-)

> I just replied on the mailing list making my points and suggestions.

This is the way.

                                -Bill

---

From: "Martin Thomson" <[email-masked]>
Date: Sat, 27 Feb 2021 22:00:00 +1100

On Fri, Feb 26, 2021, at 22:56, Vittorio Bertola wrote:
> My experience is the exact opposite - there were a number of times in 
> which I wanted to propose text for a document, but then I was pointed 
> at Github, and I am not at ease with it and did not have a lot of time 
> for it. So I gave up or, 

So anyone who asked you to submit an issue or write a pull request should be aware that sometimes they too need to make some effort.

As a request, asking someone to contribute on GitHub is fine. It isn't mandatory though. If you are able to, or you plan to contribute often, taking the effort makes it a lot harder for editors to take your input, track it, and integrate changes. However, if you don't, then it is best for all involved if the editors do the work of opening issues and writing pull requests (if that is how they manage the document). We did that for the IESG with QUIC, and for those who were unfamiliar with the process.

The goal should be always to take good input when it is offered. However, it always pays to make your input easier to act on. Clear, actionable input is more likely to result in actions, human nature being what it is. It is meeting in the middle. Editors are volunteering their effort too.

What we have found is that the discussion is sometimes more work to manage, for both editors and those involved, particularly when it comes to negotiating specific text. But generally the results are far superior.

To take an example, there was a discussion about the operational implications of path MTU discovery in QUIC. The initial issue was not especially clear to everyone involved, and the proposed text was not perfect either, but the resulting discussion clarified everything and the final text is crisp, precise, broadly acceptable, and - from my perspective - excellent. I have seen that work on a mailing list before and frankly, it is not so different in the end. Both methods can produce these good outcomes. I find the mailing list version quite a bit less efficient, that is all.

What really differs is that on the mailing list, you won't get that sort of engagement on every change. With QUIC, we had that level of engagement on every sentence that was added. So yeah, it cost more, in several ways. One way being that it was not suitable for casual engagement, something that I think needs work, as not every document needs that same level of intensity.

I am happy with the results and would recommend the process.

Understanding its limitations is important though.  We are still learning as a community, even if some of us are very familiar with it.  Collectively knowing what is possible, what works, what to avoid, and when, will take some time. I can't, however, accept any of the arguments presented so far that imply that this is bad enough to stop. And the suggestion that this is, or even might be, inherently exclusionary is one I just don't see. Our goal has always been to offer more ways to engage. At worst, I would suggest that your experiences are part of us all learning together.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 27 Feb 2021 14:53:52 +0000

Hiya,

I'm generally fine with use of github, and agree with Martin
that we're learning and need to learn more how to handle that
better, esp. wrt managing discussion on mailing lists vs. in
github issues. One point though...

On 27/02/2021 11:00, Martin Thomson wrote:
> And the suggestion that this is, or even might be, inherently
> exclusionary is one I just don't see.
I think it can be exclusionary but I'd not say "inherently"
though. If one has a bunch of people in similar TZs who are
all happy working via github issues then that can very easily
exclude participants who prefer working via the mailing list
who are not in a close enough TZ. I've experienced that when
it results in dozens of github notification emails only a few
of which are human readable, the net result of which is that
the discussion has moved on before excluded participants had
a chance to contribute and/or where it's too much work to
try extract the real discussion from the notification chaff.

I'd say it'd be good to try experiment with ways to bring
the mailing list back into discussion in such situations
whenever there's an "interesting" flurry of github exchanges
that seems to come to resolution amongst those active on
github. It's probably unrealistic for WG chairs to spot all
such events, so would depend on participants themselves who
want to be inclusive like that.

Cheers,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 27 Feb 2021 12:15:12 -0500

Barbara's thoughts got me thinking about how the experience of creating EV
certs is relevant to TERM.

Being the person who sent out the invites to the meeting that led to the
creation of EV, I think I know what they were originally supposed to be
about which was essentially a way to stop the 'race to the bottom' in
certificate validation by establishing an industry-wide minimum validation
criteria establishing accountability that was essentially VeriSign Class 3.

Going in, we expected that there would of course have to be changes that
forced us to do stuff differently as well because thats part of the game.
But we expected EV would be essentially OV and so did everyone else.

After we got started, we suddenly realized that nothing of the sort was
possible and the rules were going to have to be much more restrictive for
one simple reason: When we wrote the VeriSign Class 3 policy and practices
we were writing rules for ourselves to avoid US screwing up. We weren't
trying to stop ourselves finding loopholes. When we started writing EV, we
had to write rules that nobody could then do an end run around. And the
result was a lot less friendly to customers and to CAs.

TERM is in a similar situation. We are going to need to deal with a lot of
cross cultural issues and even within the Anglosphere.

Take the OK hand gesture. Until a few years ago it had no facsist
associations whatsoever. Then a group of racists on 4-Chan decided to start
using the gesture 'pretending' it to be a racist gang sign. And of course
the minute that racists started flashing it as a gang sign, it became a
racist gang sign. And of course, deliberately insulting people and then
telling them they must treat it as a joke or they will 'look stupid', is
simply a way to double down on the insult. Bully, bully. swagger, swagger,
sneer, sneer, oh why are we being cancelled?

Meaning is determined by usage. Who is using the term, why they are using
it, matter.

And yes, there is a partisan political dimension to this. I didn't remove
the terms 'master' etc.' from the Mesh specifications because I was
concerned they might cause offense. I removed them because I want to make
absolutely clear that I oppose the fascist seditionists who stormed the US
Capitol on January 6th.

When a bully appears and attempts to appropriate the US flag as his own
personal banner, there has to be resistance. Defining the exact means by
which the US flag is to be worshiped by taking away the career of the man
who defied him was a way of claiming sole ownership of the interpretation
of the nation's symbols. Which was of course the reason we needed to
demolish the monuments to their ideology.

The IETF has made its political position on censorship and privacy clear.
And now a very large number of US corporations are making their political
position opposing racism clear.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 28 Feb 2021 00:00:34 -0300

Hello , Phillip,

On 27/2/21 14:15, Phillip Hallam-Baker wrote:
[....]
> 
> TERM is in a similar situation. We are going to need to deal with a lot 
> of cross cultural issues and even within the Anglosphere.
> 
> associations whatsoever. Then a group of racists on 4-Chan decided to 
> start using the gesture 'pretending' it to be a racist gang sign. And of 
> course the minute that racists started flashing it as a gang sign, it 
> became a racist gang sign. And of course, deliberately insulting people 
> and then telling them they must treat it as a joke or they will 'look 
> stupid', is simply a way to double down on the insult. Bully, bully. 
> swagger, swagger, sneer, sneer, oh why are we being cancelled?
> 
> 
> Meaning is determined by usage. Who is using the term, why they are 
> using it, matter.

I'm not sure what this means.  That said, given the number of countries 
and cultures on this globe, I doubt anyone could really expect that 
people should be aware about stuff like the stuff you're referencing.

For instance, I don't know what's 4-chan (some online forum?), or even 
what you call the "ok sign" -- here we probably have at least to 
different signs for it.

In a multi-cultural environment, you probably *need* to apply Postel's 
principle.

> And yes, there is a partisan political dimension to this. I didn't 
> remove the terms 'master' etc.' from the Mesh specifications because I 
> was concerned they might cause offense. I removed them because I want to 
> make absolutely clear that I oppose the fascist seditionists who stormed 
> the US Capitol on January 6th.

I believe that our ability to do useful work may be endangered if our 
documents are going to become "political statements".

(quite the contrary, there reason for which I'd be keen to avoid 
specific terms is for the possibility that might offend e.g. a fellow 
colleague)

> which the US flag is to be worshiped by taking away the career of the 
> man who defied him was a way of claiming sole ownership of the 
> interpretation of the nation's symbols. Which was of course the reason 
> we needed to demolish the monuments to their ideology.

This thread was started in the hopes of fostering diversity and 
inclusiveness in the IETF.

I don't think discussion of USA internal political affairs is of use for 
such purpose.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Sun, 28 Feb 2021 00:07:35 -0300

On 27/2/21 08:00, Martin Thomson wrote:
[...]
> 
> The goal should be always to take good input when it is offered. However, it always pays to make your input easier to act on. 

Probably the key issue is discussion vs pull requests.

Pull-requests are certainly very actionable and nice (assumming a 
documents is being managed with github). OTOH, it would be nice if the 
discussion that lead to the pull request involves the broader audience.

If mailing-lists are supposed to be required for consensus, then it 
would seem that a reasonable expectation is that discussions take place 
on the mailing-lists -- this doesn't preclude pull requests to 
eventually apply changes to a document.

Thanks,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 27 Feb 2021 22:53:42 -0500

> people should be aware about stuff like the stuff you're referencing.

Oh I am pretty sure most people understood the point.

> what you call the "ok sign" -- here we probably have at least to

Again, you seem to have got my point.

And none of that changes Wittgenstein's point that meaning is usage and the
reason certain symbols become offensive is that some groups decide to use
them for the purpose of giving offense. There was nothing offensive about
the penitents robes of the la Borriquita brotherhood until Hollywood
decided to adopt them as the uniform of the Klu Klux Klan which at the time
had been extinct for decades. Today, they are almost universally understood
as a hate symbol.

> documents are going to become "political statements".

That is inescapable in an environment where people have been told they must
take sides.

> specific terms is for the possibility that might offend e.g. a fellow

It is not about merely giving offense. This is about the use of words to
tell people that they are less important than others.

> I don't think discussion of USA internal political affairs is of use for

The rise of populist authoritarianism was hardly limited to one country.
And while the role of the Internet and social media were rather different
to that being asserted by some, we certainly played a role

The reason I am bringing up the political context directly is that is the
only thing that makes these proposals important. We would not be making
expensive changes to APIs if this was merely about offense. The reason that
we are getting rid of terms like 'master' and 'slave' in protocol
specifications is not some urge to follow some abstract left wing fashion.
The reason we are eliminating 'master' and 'slave' is because there has
been a resurgence of support for the racism and last month a white
supremacist carried the banner of the slaver confederacy through the US
capitol.

---

From: Keith Moore <[email-masked]>
Date: Sat, 27 Feb 2021 22:58:41 -0500

On 2/27/21 10:53 PM, Phillip Hallam-Baker wrote:

> The reason I am bringing up the political context directly is that is 
> the only thing that makes these proposals important. We would not be 
> making expensive changes to APIs if this was merely about offense. The 
> reason that we are getting rid of terms like 'master' and 'slave' in 
> protocol specifications is not some urge to follow some abstract left 
> wing fashion. The reason we are eliminating 'master' and 'slave' is 
> because there has been a resurgence of support for the racism and last 
> month a white supremacist carried the banner of the slaver confederacy 
> through the US capitol.

Not that I disagree entirely (and I'm as livid about the coup attempt as 
anyone), but I do think it's problematic if a global organization is 
expected to cater to conventions of US society and bend to US cultural 
baggage.

Keith

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 27 Feb 2021 23:12:28 -0500

> expected to cater to conventions of US society and bend to US cultural

Yes and no. It really depends on the issue. The reason this has particular
valency at this particular time is peculiar to the US. The principle is
universal.

Most often its other countries that prod us to take sides... Like we have
on censorship and privacy.

But lets take an older example. Back in 500BCE, infant sacrifices were
pretty much universal among the cultures bordering the mediteranean. These
were disrupted somewhat by Alexander's conquests which didn't get as far as
Carthage because he died.

One side effect of this was that by the time Rome and Carthage came into
conflict, while both cities practiced human sacrifice it was on a vastly
greater scale in Carthage, a fact that Rome quickly seized on as a
propaganda weapon.

And once it is decided to make use of the fact that the enemy engages in
some perfidious practice, well you really have to stop doing it at home. So
by the time Hannibal's elephants are marching through the alps, Rome has
completely stopped with the human sacrifice thing. Human sacrifice is the
worst possible thing ever and the fact children were being sacrificed to
Saturn only a few generations earlier is forgotten. Oh and those gladiator
contests... well just don't call them human sacrifices.

Point is that powerful cultural taboos don't have to be recreated in every
country. Once established in one place, doing the right thing can spread
quickly.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 28 Feb 2021 01:40:10 -0300

Hello, Phillip,

On 28/2/21 00:53, Phillip Hallam-Baker wrote:
> 
> 
> On Sat, Feb 27, 2021 at 10:01 PM Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hello , Phillip,
> 

I was noting that *I* wasn't sure what that meant.

> And none of that changes Wittgenstein's point that meaning is usage and 
> the reason certain symbols become offensive is that some groups decide 
> to use them for the purpose of giving offense.

Symbols become offensive for what people associate with them, based on 
their background and personal history.

If you plan to get rid of e.g. "signs" for how they may have been used 
by some, I bet you'd also propose to get rid of religious symbols, and 
national symbols such as flags -- because in the vast majority of such 
cases, at one point or another they have been associated with (and 
actually involved in) terrible things.

> There was nothing 
> offensive about the penitents robes of the la Borriquita brotherhood 
> until Hollywood decided to adopt them as the uniform of the Klu Klux 
> Klan which at the time had been extinct for decades. Today, they are 
> almost universally understood as a hate symbol.

Not really. A lot of people over here wouldn't associate those with the kkk.

> That is inescapable in an environment where people have been told they 
> must take sides.

That doesn't make it right, or even appropriate.

(Also, in the words of Wittgenstein "Whereof one cannot speak, thereof 
one must be silent")

> tell people that they are less important than others.

You are implying *intent*. In many cases (or in some places), it might 
be the case. In others, it might not.

(see e.g. 
https://www.france24.com/en/live-news/20210115-cavani-s-racism-ban-an-attack-on-a-culture 
  or 
https://www.batimes.com.ar/news/sports/uruguayan-players-union-slams-english-fa-for-cavani-racism-ban.phtml 
)

> The rise of populist authoritarianism was hardly limited to one country.

You imply that certain events are of utmost concern to the global community.

Please let me note that for some of us in such global community, a large 
number of other events (including former presidents commonly portrayed 
as "patriots") have been a much larger concern. -- Please do check e.g. 
USA foreign policy of at least the last 50 years.

> And while the role of the Internet and social media were rather 
> different to that being asserted by some, we certainly played a role
> 

I'll unfortunately repeat myself here: IETF is supposed to be a global 
organization. Please don't expect the global community to discuss (or 
even be aware of) USA domestic affairs.

It's kind of ironic that in an email thread about diversity and 
inclusiveness in a global organization, participants are expected to 
discuss the domestic affairs of one -- no matter how prominent -- of the 
many countries where participants come from.

Thanks,

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 28 Feb 2021 16:45:36 +0000

I don't think that conclusion follows. For example, many WG's have design team meetings that work on draft text which is then merged and reviewed by the group. In addition, after an in-person IETF meeting, we usually send an email asking if others object to the consensus decisions we made there. I have done this myself, as co-chair of a few working groups, and seen it all the time in others.  The phrase is "confirmed on the mailing list."

For another reason, the best PR's come from discussion and suggestions *in the PR* not a disparate email thread.

---

From: John Wroclawski <[email-masked]>
Date: Sun, 28 Feb 2021 22:37:25 -0500

> On Feb 25, 2021, at 4:21 PM, Brian E Carpenter <[email-masked]> wrote:

Seconding Brian’s comment (and Keith’s in the next msg), the DOI effort and CCR articles were excellent, necessary first steps, but by themselves they’re not likely to change the landscape very much, I think.

The issue is more fundamental. Academia wishes to claim that its highest value publications are “original research”, and consensus-driven standards with the stated goal of codifying existing or emerging practice don’t “look” like that. My weasel words are because both sides of this stereotype are sometimes truly true and sometimes, well, not. But it's the perception, and it’ll be really hard to get the academic publication world to weigh RFCs heavily without changing it in some way.

Which, I think, might possibly be doable. Academia does have other values - you can get brownie points for a good survey paper, for example, because you’re "systematizing knowledge" - and increasingly (although not as much as one might hope) work that validates research results by showing the they’re repeatable is seen as publishable. But the trick here is to frame this as a case that RFCs and IETF participation advance some substantive academic value - not just to argue that they follow the “form” of academic publication by being peer-reviewed and having DOIs. I’m not sure if anyone’s every quite tried to do this, but it seems at least potentially possible.

—john