Subject: [Gendispatch] Fwd: New Version Notification for draft-gondwana-effective-terminology-01.txt

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 25 Aug 2020 21:40:22 +1000

I did promise that I'd draft something up as an alternative terminology starting point.  I've done some revising based on feedback from a couple of people I cross checked this with, but it's definitely nowhere near "done".

My key goals are:
* make sure we celebrate the good work that the IETF has done and continues to do while talking about ways we could improve
* acknowledge the real cost of changing terminology and that there are risks involved, while also making it clear that change is sometimes needed and delaying it makes it more expensive, not less
* make the mechanism for filtering unwanted words be author persuasion and review pressure, not a set of outright forbid
den words, as that's more scaleable and responsive to the outside world

I had a couple of people review this for me privately to make sure I wasn't doing something totally insane here, thanks to them for the pointers.  I posted -00 as well so everyone can see where I came from - and the github repo also has the original commit.

Chairs, I would appreciate some time to talk about this draft at the upcoming interim meetings.

Thanks,

Bron.

----- Original message -----
From: [email-masked]
To: Bron Gondwana <[email-masked]>
Subject: New Version Notification for draft-gondwana-effective-terminology-01.txt
Date: Tuesday, August 25, 2020 21:34

A new version of I-D, draft-gondwana-effective-terminology-01.txt
has been successfully submitted by Bron Gondwana and posted to the
IETF repository.

Name: draft-gondwana-effective-terminology
Revision: 01
Title: Effective Terminology in IETF drafts
Document date: 2020-08-25
Group: Individual Submission
Pages: 7
URL:            https://www.ietf.org/internet-drafts/draft-gondwana-effective-terminology-01.txt
Status:         https://datatracker.ietf.org/doc/draft-gondwana-effective-terminology/
Htmlized:       https://tools.ietf.org/html/draft-gondwana-effective-terminology-01
Htmlized:       https://datatracker.ietf.org/doc/html/draft-gondwana-effective-terminology
Diff:           https://www.ietf.org/rfcdiff?url2=draft-gondwana-effective-terminology-01

Abstract:
   The IETF and the RFC series are trusted names, for producing high
   quality technical documents that make the Internet work better.

   While the success of our documents is variable, many of them are
   widely used over a long time period.

   As norms in the outside world change, our documents need to remain
   relevant and accessible to future generations of those working on the
   internet, everywhere in the world.

   This longevity of our documents, and the impossibility of predicting
   the future, implies that we should be conservative in the language
   that we send.  Effective language expresses our intent with clarity,
   and without distraction.

   This document describes a glossary for increasing awareness of terms
   which are going to be clear and effective without turning readers
   away, to enable our mission of making the Internet work better.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Aug 2020 08:51:55 +1200

Bron,

Thanks for this. I like the tone and the choice of language. Just one remark:

> 5.  IANA Considerations
> 
>    This document does not ask the IANA to do anything (unless we decide
>    that IANA is a good place for a central glossary to be kept)

I think IANA would be a bad place for that, but my reaction was to identify
a missing section:

5a.  RFC Editor Considerations

   This document does not ask the RFC Editor to do anything (unless we decide
   that the RFC Editor site is a good place for a central glossary to be kept).

On the other hand, maybe it isn't useful for us to keep any such glossary
anywhere.

Regards
   Brian

On 25-Aug-20 23:40, Bron Gondwana wrote:
> From: [email-masked] <mailto:[email-masked]>
> To: Bron Gondwana <[email-masked] <mailto:[email-masked]>>

---

From: "John Levine" <[email-masked]>
Date: 25 Aug 2020 22:29:52 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-
>
>I did promise that I'd draft something up as an alternative terminology starting point.  I've done
>some revising based on feedback from a couple of people I cross checked this with, but it's
>definitely nowhere near "done".

Thanks -- this is a fine piece of work.

It lays out the issues using clear language and avoids external
appeals to authority (something guarnated to backfire in this crowd.)
It speaks to its readers as peers.

It's certainly not perfect but it's a big step forward from where we
were a few days ago.

R's,
John

PS: Apropos Brian's remarks. we already have an RFC style guide, so that's
the natural place to put any advice on terminology.

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 26 Aug 2020 14:02:02 +1000

> On the other hand, maybe it isn't useful for us to keep any such glossary

Good point :)  I didn't expect that I'd get everything right in the firstsecond draft, so very happy to have feedback.

Without a glossary somewhere the document doesn't really do much at all other than defend the status quo and outline that the IETF generally follows terminology norms that are emerging in the wider community rather than forming them, which maybe has some value in itself - but at that point maybe there's no value in the document!

Cheers,

Bron.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 26 Aug 2020 10:09:46 -0700

On 8/25/2020 9:02 PM, Bron Gondwana wrote:
> Good point :)  I didn't expect that I'd get everything right in the
> firstsecond draft, so very happy to have feedback..
>
> Without a glossary somewhere the document doesn't really do much at
> all other than defend the status quo and outline that the IETF
> generally follows terminology norms that are emerging in the wider
> community rather than forming them, which maybe has some value in
> itself - but at that point maybe there's no value in the document!

Quick feedback to Bron: I like the tone of most of your draft, but you
can't get away without addressing the specific issues listed by Mallory
and Niels, "master-slave" and "white/black list". Also, your security
section has a marked departure in tone with a reference to "bad faith
actors." We are witnessing a contentious debate in which I don't think
participants are acting in "bad faith", rather than say, deeply held
convictions. At a minimum, you need to change the tone, but I think you
have to actually change the meaning, because that section goes too far.

Suppose a reviewer calls out the use of obsolete metaphors in a last
call review, pointing out for example the use of "master/slave". Your
text as written empowers the WG chair to discard such comments because
they "are harder to prove or evaluate than other claims". That's not the
outcome that we want. We have a rough consensus to not use such terms in
future documents, and WG chairs should not be directed to ignore that
consensus. Fighting that consensus would also be a way "to derail the
IETF from its mission, and to use the IETF's brand as clout in political
battles" -- just a different side of the political battles.

-- Christian Huitema

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Aug 2020 20:50:07 +0200

Hi Christian,

> Quick feedback to Bron: I like the tone of most of your draft, but you can't get away without addressing the specific issues listed by Mallory and Niels, "master-slave" and "white/black list".

It seems to me that Bron is dereferencing to a glossary, not all that different from what Alissa posted, and then deferring to the working group, document authors, and the consensus process as to what to do next.  As an author I will tell you, and I am sure you feel the same, the last thing I want to do in a technical specification is get wrapped around the axle on terminology that might offend someone.  Who here would stand on their heads with such a thing?  The only time would be if people were being entirely unreasonable in terms of claiming certain words were offensive, when it was plainly clear they were not.

> Also, your security section has a marked departure in tone with a reference to "bad faith actors." We are witnessing a contentious debate in which I don't think participants are acting in "bad faith", rather than say, deeply held convictions. At a minimum, you need to change the tone, but I think you have to actually change the meaning, because that section goes too far.
> Suppose a reviewer calls out the use of obsolete metaphors in a last call review, pointing out for example the use of "master/slave". Your text as written empowers the WG chair to discard such comments because they "are harder to prove or evaluate than other claims". That's not the outcome that we want. We have a rough consensus to not use such terms in future documents, and WG chairs should not be directed to ignore that consensus.
> 
IMHO I don’t think we have that consensus, and I don’t think we should try for consensus on specific words or phrases or the IETF will definitely have departed from its mission to the language police absent context.  Case and point: do you think anyone would ever create a new use for master/slave, knowing the hell that will come at them?

> Fighting that consensus would also be a way "to derail the IETF from its mission, and to use the IETF's brand as clout in political battles" -- just a different side of the political battles.
> 

Not following you.

Eliot

Eliot

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Aug 2020 15:45:52 -0400

On 8/26/20 1:09 PM, Christian Huitema wrote:

> We have a rough consensus to not use such terms in future documents

If that rough consensus has been established, I've missed it.

Keith

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 27 Aug 2020 08:28:58 +1000

On Thu, Aug 27, 2020, at 03:09, Christian Huitema wrote:

>> Good point :)  I didn't expect that I'd get everything right in the firstsecond draft, so very happy to have feedback..
>> 

> Quick feedback to Bron: I like the tone of most of your draft, but you can't get away without addressing the specific issues listed by Mallory and Niels, "master-slave" and "white/black list". 

Well, I'm hoping I can avoid addressing those specific terms because they are a point-in-time issue, and I'm trying to establish what there is consensus on.

My reading of the traffic on the IETF list is that there is quite definitely not consensus in the IETF on those specific terms.

> Also, your security section has a marked departure in tone with a reference to "bad faith actors." We are witnessing a contentious debate in which I don't think participants are acting in "bad fait…

I'm happy to change the tone here.

When I wrote this I was thinking of spurious things like "work is oppression and the word network is derived from work, so you need to remove the word network from all RFCs back into the past or you are oppressing me".  There needs to be a reasonableness test that can declare that as being in bad faith or otherwise defend against it.

> Suppose a reviewer calls out the use of obsolete metaphors in a last call review, pointing out for example the use of "master/slave". Your text as written empowers the WG chair to discard such comments because they "are harder to prove or evaluate than other claims". That's not the outcome that we want. We have a rough consensus to not use such terms in future documents, and WG chairs should not be directed to ignore that consensus. Fighting that consensus would also be a way "to derail the IETF from its mission, and to use the IETF's brand as clout in political battles" -- just a different side of the political battles.

My text needs to empower the working group to discard the "network" case above.  We already have mechanisms to deal with working group chairs who operate wildly outside the IETF's norms.  We don't need a specific way to hit a chair over the head for rejecting a reviewer for this issue as opposed to rejecting a review for a technical issue.

This is not directing chairs to ignore any consensus that might exist on any specific words over time, it's deliberately NOT giving this particular issue a different process than any other review.

Regards,

Bron.

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 27 Aug 2020 08:33:36 +1000

> My reading of the traffic on the IETF list is that there is quite definitely not consensus in the IETF on those specific terms.

Self-followup.  To clarify I think there is close to a consensus that avoiding the word "slave" is worthwhile, and I would not expect to see new specifications using it.  I don't believe there's consensus on deprecating b/w lists, or the word "master" when standalone or paired with different alternates.

Bron.

---

From: Keith Moore <[email-masked]>
Date: Wed, 26 Aug 2020 20:33:16 -0400

For what it's worth, I'm generally in support of Bron's draft. I view 
our drafts as potentially complimentary to one another rather than 
competing.

(I didn't read his draft until I finished mine.)

Keith