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)" <a...@cisco.com> To: "Mike Fox" <mj...@us.ibm.com>, "lsr@ietf.org" <lsr@ietf.org> Date: 11/16/2021 04:10 PM Subject: [EXTERNAL] Re: [Lsr] Issues with master/slave terminology in OSPF 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" <lsr-boun...@ietf.org on behalf of mj...@us.ibm.com> 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 ---------------------------------------------------------------------------- IBM Enterprise Network Solutions Architecture & Design ---------------------------------------------------------------------------- Research Triangle Park, NC USA _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
