Christian Huitema wrote:
Sorry, I mistyped. The statement was issued on May 11, 2021: https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/
Thanks. Though it should be more "inclusive" if you provided the pointer in the original mail, IESG is not requiring such "high quality" for our daily mails, I really hope. Anyway, my point in https://mailarchive.ietf.org/arch/msg/ietf/szfzLAbV9EmQ7kmz3HGfaLkLhT0/ is that rephrasing master/slave as primary/secondary actually authorize the attempt of racial discrimination *VERY* long after slavery was constitutionally illegalized in US in 1865. There are so many people who superficially interpreted the 13th amendment to continue racial discrimination legally. Finally, around 1964, the Civil Rights Act and the Voting Rights Act was enacted to illegalize to treat blacks as secondary citizens. But, seemingly, racial discrimination without slavery in US still exists even today. As such, I must say that quality of NIST document to propose, though weakly as "potentially biased language", to rephrase master/slave as primary/secondary is poor produced by people having less knowledge on US history of racial discrimination than me. Following such a poor document reduces the quality of our RFCs. In addition, requiring to follow the NIST document raises the bar of language barrier for us non native speaker of English, which is against inclusiveness, which means wasted effort for the poor document will reduce technical quality of our RFCs. Moreover, I can see no reason for IETF or ITU (ACM and IEEE should be US local organizations) bothered by US local and, obviously misdirected, issue for "inclusive language". As a technical/engineering body, IETF should pursue technical/engineering inclusiveness without paying any attention for superficial and often wrong inclusiveness. Masataka Ohta
