Subject: [Lsr] Issues with master/slave terminology in OSPF

From: "Mike Fox" <[email-masked]>
Date: Tue, 16 Nov 2021 16:53:20 -0400

Many companies in the industry including mine are undergoing initiatives 
to replace offensive terminology in IT.  One of the targeted terms is 
master/slave, which is used in OSPF database exchange and the terms appear 
in various documentation and displays for our OSPF routing daemon.  I'm 
still waiting on guidance on whether or not  industry-standard terms get a 
pass, but it's not looking good.  Has anyone else encountered this issue 
and if so how have you handled it? If I'm going to need to change to 
terminology that does not match the RFC I'd like to be consistent with 
what others are doing. 

Thank you,
Mike
----------------------------------------------------------------------------
IBM Enterprise Network Solutions Architecture & Design
----------------------------------------------------------------------------
Research Triangle Park, NC  USA

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 16 Nov 2021 21:09:55 +0000

The IETF is already applying these standards to new documents. 

https://www.ietf.org/archive/id/draft-knodel-terminology-07.txt

At some point, I'd expect that someone with the time and energy will produce a single document that updates all the existing documents using the updated terminology. At least that would be my preference since doing BIS versions of all these documents is not desirable unless this is being done for other purposes. For example, it would not make sense to do an RFC 2328 BIS unless we were going to also correct all the Errata and go through a full review cycle. 

Thanks,
Acee

On 11/16/21, 3:55 PM, "Lsr on behalf of Mike Fox" <[email-masked] on behalf of [email-masked]> wrote:

    Thank you,
    Mike

    _______________________________________________
    Lsr mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/lsr

---

From: "Mike Fox" <[email-masked]>
Date: Tue, 16 Nov 2021 17:41:33 -0400

Thank you for the update Acee.  If I am required to make the change before 
the RFC gets updated (which sounds like it could be a while) I'd like to 
pick terms that are likely to line up with what it eventually changes to 
but at this point I'd be guessing.  The usual suggested substitutions 
along the lines of manager/worker don't seem to work well considering how 
the database exchange works, so I'm thinking if it's up to me I change it 
to speaker/responder but I'd like to get feedback on the terms others are 
using.. if any other OSPF products have tackled this already I'd be 
curious what terms they adopted. 

Mike
----------------------------------------------------------------------------
Enterprise Network Solutions Architecture & Design
----------------------------------------------------------------------------
Research Triangle Park, NC  USA

From:   "Acee Lindem (acee)" <[email-masked]>
To:     "Mike Fox" <[email-masked]>, "[email-masked]" <[email-masked]>
Date:   11/16/2021 04:10 PM
Subject:        [EXTERNAL] Re: [Lsr] Issues with master/slave terminology 
in OSPF

At some point, I'd expect that someone with the time and energy will 
produce a single document that updates all the existing documents using 
the updated terminology. At least that would be my preference since doing 
BIS versions of all these documents is not desirable unless this is being 
done for other purposes. For example, it would not make sense to do an RFC 
2328 BIS unless we were going to also correct all the Errata and go 
through a full review cycle. 

Thanks,
Acee

On 11/16/21, 3:55 PM, "Lsr on behalf of Mike Fox" <[email-masked] 
on behalf of [email-masked]> wrote:

    Many companies in the industry including mine are undergoing 
initiatives 
    to replace offensive terminology in IT.  One of the targeted terms is 
    master/slave, which is used in OSPF database exchange and the terms 
appear 
    in various documentation and displays for our OSPF routing daemon. I'm 

    still waiting on guidance on whether or not  industry-standard terms 
get a 
    pass, but it's not looking good.  Has anyone else encountered this 
issue 
    and if so how have you handled it? If I'm going to need to change to 
    terminology that does not match the RFC I'd like to be consistent with 

    what others are doing. 

    Thank you,
    Mike

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 16 Nov 2021 15:45:36 -0600

On November 16, 2021 at 4:10:16 PM, Acee Lindem wrote:

Hi!

> The IETF is already applying these standards to new documents.

The better reference to what the IETF is doing is this one:
https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/

> At some point, I'd expect that someone with the time and energy will produce
> a single document that updates all the existing documents using the updated
> terminology. At least that would be my preference since doing BIS versions
> of all these documents is not desirable unless this is being done for other
> purposes. For example, it would not make sense to do an RFC 2328 BIS unless
> we were going to also correct all the Errata and go through a full review
> cycle.

I agree on your point about rfc2328bis.

OTOH, I don't think that a mass update would work as expected simply
because the terminology may not be used within the same context in all
cases, so a common replacement may not always make sense.

For the case that Mike points at, I think we could "simply" publish a
document that Updates rfc2328 and explains what the new terminology
should be -- assuming the WG is ok with it.  I would think that
something like primary/secondary or leader/follower could work.

My 2c.

Alvaro.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 16 Nov 2021 21:44:50 +0000

Hi Mike, 

On 11/16/21, 4:42 PM, "Mike Fox" <[email-masked]> wrote:

If I interpret it correctly, the Knodel draft suggests "primary/secondary".  However, this is not an RFC yet. 

Thanks,
Acee

    Mike

    Thanks,
    Acee

        what others are doing. 

        Thank you,
        Mike

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 16 Nov 2021 22:00:10 +0000

Hi Alvaro, 

On 11/16/21, 4:46 PM, "Alvaro Retana" <[email-masked]> wrote:

    Hi!

Thanks - I didn't look in the right place for this... 

Agree - leader/follower would be better in this context but I didn't see it in the Knodel draft. Hopefully, this terminology is acceptable. 

Thanks,
Acee

    My 2c.

    Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 16 Nov 2021 16:25:07 -0600

On November 16, 2021 at 5:00:16 PM, Acee Lindem wrote:

[A little detour from Mike's topic.]

> ...but I didn't see it in the Knodel draft. Hopefully, this terminology is
> acceptable.

The terminology list (which is where the Knodel draft was being
discussed) "expressed strong support for the sentiment that the
guidance on inclusive language in [NISTIR8366] is suitable for the
IETF as well..." [Quoting from [1].]

IOW, look at the NIST document, not the draft.

Alvaro.

[1] https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/

[NISTIR8366] https://doi.org/10.6028/NIST.IR.8366

---

From: tom petch <[email-masked]>
Date: Thu, 18 Nov 2021 17:09:34 +0000

From: Lsr <[email-masked]> on behalf of Mike Fox <[email-masked]>
Sent: 16 November 2021 20:53

<tp>

Mike

The IESG statement triggered a lengthy discussion on the main IETF list 23jul2020 which was shut down by the IETF Chair as unhelpful 11aug20.   (There are references to the 'terminology' list but I do not know what went on there).

The use of master and slave got quite an airing and the sense I got was that the referenced documents, of which there are several from several sources, do not address the issue of a controlling and controlled entity as is common in electronics, protocols and engineering in general.  There might have been some progress in the past year but I see no evidence thereof.

Equally, my sense was that there was no consensus in support of taking draft-knodel as a way forward, political pressure perhaps, but not IETF consensus.

Tom Petch

Thank you,
Mike