My personal .02 - This is a worthwhile topic for the community to consider, and past due. However, it may be best to defer discussion of a Series-wide policy until we have a "full" RFC Series Editor (or the replacement for that role). Such a policy would inevitably place requirements on the RFC Editor, and may involve updating existing documents -- both contentious topics in the rfced-future program. And, while John is (IMO) a good candidate for owning such a discussion, the Temporary RFC Series Project Manager role explicitly excludes strategic ownership. In the meantime, I think we should encourage individual streams to define policies on the terminology they use in drafts. For example, the IESG could formulate a (shorter) statement, circulate it in the community for discussion, and then post it. The IAB, IRTF and Independent streams could adopt that policy if they wished, or define their own. This would also allow us to gain some operational experience with such a policy before nailing it down in an RFC. Cheers, P.S. I'm seeing 'main' used as a replacement for 'master' in a few places; e.g., `git checkout main` is easier, because you can type `ma` and then tab complete. > On 24 Jul 2020, at 2:35 am, The IESG <iesg@xxxxxxxx> wrote: > > The IESG believes the use of oppressive or exclusionary language is > harmful. Such terminology is present in some IETF documents, including > standards-track RFCs, and has been for many years. It is at odds with > our objective of creating an inclusive and respectful environment in the > IETF, and among readers of our documents. > > The IESG realizes that the views of the community about this topic are > not uniform. Determining an actionable policy regarding problematic > language is an ongoing process. We wanted to highlight that initial > discussions about this topic are taking place in the general area (a > draft [1] is slated for discussion in GENDISPATCH [2] at IETF 108). > Updating terminology in previously published RFCs is a complex endeavor, > while making adjustments in the language used in our documents in the > future should be more straightforward. > > The IESG looks forward to hearing more from the community, engaging in > those discussions, and helping to develop a framework for handling this > issue going forward. > > [1] https://datatracker.ietf.org/doc/draft-knodel-terminology/ > [2] https://www.ietf.org/proceedings/108/agenda/agenda-108-gendispatch-03 > -- Mark Nottingham https://www.mnot.net/
