Re: IESG Statement On Oppressive or Exclusionary Language

[Joseph Touch <[e-mail]>]

> On Jul 28, 2020, at 10:25 PM, Viktor Dukhovni <[e-mail]> wrote:
> 
> On Mon, Jul 27, 2020 at 09:28:41AM -0700, Joseph Touch wrote:
> 
>>> The potential for a small but motivated group to hijack the process
>>> and dictate policy is great, and the argument that the process was
>>> open to everyone is not convincing. We all have limited time, and
>>> arguing language policy at the IETF is not a good use of time for
>>> most of us.  
>> 
>> You could say the same for the documents at the core of many current WGs. 
> 
> But Yoav explained in detail why this case is different, by nature of
> its scope and difficulty of achieving rough consensus from the community
> large, and not just a few brave and/or foolhardy enough to take the bait
> and spend time discussing a not terribly fun topic.

Those are exactly the reasons this case is identical to other IETF docs.

>> We’re not trying to ban words; we’re trying to help those who might
>> not realize otherwise when certain words have current connotations
>> they might not have intended.
> 
> You say we, but I don't consider myself sufficiently elevated above the
> hoi polloi to be quite so paternalistic.  The authors know what they
> intended, and their peers in the WG, IETF LC, IEST and finally the RSE
> will read the documents and will suggest clearer/better language where
> that intent is liable to be misunderstood by others.

And that’s all this document is intended to assist. As I mentioned before, it compels only the RSE to support the process. Authors are encouraged to help by participating too, but not compelled.
,,,
> The language used in IETF documents will reflect the norms of the time
> in which they were written, and so it should be.

And what this doc is recognizing is that these norms now include addressing potentially unintended connotations of the terms it lists.

Further, it also can help us in encouraging consistent use of new terms. If we each choose different versions of replacements, the result could be confusing. Suggesting why “primary/secondary” is not a good choice for DNS (for which primary already has other meanings), e.g., could be very useful.

...
> Noone should be afraid to use existing terms of art that were clear
> enough last year, but if in the document review process alternative
> terms find more support, they should be used instead.  …


The proposed document helps us have that discussion collectively now, rather than ad-hoc for each RFC published. That’s all it is intended to do.

Joe