Subject: [IETFMIBS] Issues with master/slave terminology in SNMP and FDDI MIBs

From: "Joshua Bennetone" <[email-masked]>
Date: Tue, 30 Nov 2021 15:02:58 -0400

Many companies in the industry including mine are undergoing initiatives to
replace offensive terminology in IT.  One of the targeted terms is master
and (whether explicitly or implicitly paired with) slave. This is used in
the AgentX protocol RFC 2741 and the description and definition of FDDI
MIBs in RFC 1285/ RFC 1512 - specifically snmpFddiSMTNonMasterCt and
snmpFddiSMTMasterCt.  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.

Best regards,
Josh Bennetone
z/OS CommServer Developer

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 30 Nov 2021 11:57:07 -0800

Hi -

On 2021-11-30 11:02 AM, Joshua Bennetone wrote:
> Many companies in the industry including mine are undergoing initiatives 
> to replace offensive terminology in IT.  One of the targeted terms is 
> master and (whether explicitly or implicitly paired with) slave. This is 
> used in the AgentX protocol RFC 2741
RFC 2741 (and its predecessors) have never used "slave", but
instead have employed "subagent."  If the term "master agent" is
problematic of itself, then SMUX (RFC 1227) and DPI (RFCs 1228
and 1592) specifications have the same issue.  A quick check
shows that the major proprietary protocol in this space also
retains the "master agent and subagent" terminology.

Good luck finding people with the energy and motivation to
find replacements for "master agent" and "subagent" and to
update what in some cases are 30 year old documents.

> and the description and definition 
> of FDDI MIBs in RFC 1285/ RFC 1512 - specifically snmpFddiSMTNonMasterCt 
> and snmpFddiSMTMasterCt.  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.

Passing on the FDDI question, and sticking to the subagent protocols...

I think I'd ask the powers that be whether the term "master"
(particularly when consistently paired with a term like "subagent")
is of itself objectionable.  If it is, the bad news is that I am
not aware of any consensus regarding replacement terms in the subagent
protocol space.

This is *very* mature technology, and I suspect a lot of the people
who have worked on it have either retired (like me) or long since
gone on to other things, so document updates are probably in the
realm of wishful thinking, unless you can recruit new people to
do the work.

Randy

---

From: Bob Natale <[email-masked]>
Date: Tue, 30 Nov 2021 20:53:05 +0000

+1.

<IMHO>
More generally, people really must take a more sophisticated approach to applying (legitimately) correct terminology. Words when used in reference to people and social contexts have a different import than when used in an inanimate domain context. People (and I mean all people) have legitimate concerns about offensive terminology in the human contexts ... those concerns really do not apply -- are not germane -- in many other contexts. I believe that most people inherently understand the distinction ... yes, there are some grey areas that need special consideration and we should do our best to exercise good judgment there (Internet protocols are not such an area) ... the easiest way out for unsophisticated people with megaphones of one form or another today is to ignore all distinctions and apply an embarrassingly simplistic blanket approach (that they are not embarrassed by such an approach is emblematic of their unsophisticated) ... alas, there are also certain "drivers" today -- e.g., social media "influencer" aspirations, mass media ratings aspirations, political power aspirations, and such -- that profitably foster, nurture, and exploit unsophisticated audiences ... these audiences are *not* dominated by people with the most valid concerns about offensive terminology in the human context.
</IMHO>

BobN

-----Original Message-----
From: IETFMIBS <[email-masked]> On Behalf Of Randy Presuhn
Sent: Tuesday, November 30, 2021 2:57 PM
To: [email-masked]
Subject: [EXT] Re: [IETFMIBS] Issues with master/slave terminology in SNMP and FDDI MIBs

Hi -

On 2021-11-30 11:02 AM, Joshua Bennetone wrote:
> Many companies in the industry including mine are undergoing 
> initiatives to replace offensive terminology in IT.  One of the 
> targeted terms is master and (whether explicitly or implicitly paired 
> with) slave. This is used in the AgentX protocol RFC 2741
RFC 2741 (and its predecessors) have never used "slave", but instead have employed "subagent."  If the term "master agent" is problematic of itself, then SMUX (RFC 1227) and DPI (RFCs 1228 and 1592) specifications have the same issue.  A quick check shows that the major proprietary protocol in this space also retains the "master agent and subagent" terminology.

Good luck finding people with the energy and motivation to find replacements for "master agent" and "subagent" and to update what in some cases are 30 year old documents.

> of FDDI MIBs in RFC 1285/ RFC 1512 - specifically 
> snmpFddiSMTNonMasterCt and snmpFddiSMTMasterCt.  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 

I think I'd ask the powers that be whether the term "master"
(particularly when consistently paired with a term like "subagent") is of itself objectionable.  If it is, the bad news is that I am not aware of any consensus regarding replacement terms in the subagent protocol space.

This is *very* mature technology, and I suspect a lot of the people who have worked on it have either retired (like me) or long since gone on to other things, so document updates are probably in the realm of wishful thinking, unless you can recruit new people to do the work.

Randy

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

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 30 Nov 2021 13:39:20 -0800

Hi -

Non-technical considerations pop up in surprising ways.
(Consider why "nu" and "xi" were skipped along the way
to "omicron".)

I think it's more productive to see whether there's
any possible consensus about a preferred term to use
as a euphemism for "master agent" if folks find it
offensive.  If someone has done that work, great!
If not, what would be some reasonable choices?

   - encapsulating agent?
   - coordinating agent?
   - marshaling agent?

(Primary / secondary fail terribly as terms if you consider
hot standby, fault tolerant configurations, etc.)

But before going too far in such a discussion, I think it's
reasonable to ask whether "master agent" (when consistently
in the context of subagents and subagent protocols with no
references to human bondage) is indeed considered objectionable.
It's not our place to pass judgement on such an assessment, but
we should confirm that such an assessment has indeed been made,
and then those with the energy can deal with it.

Randy

---

From: Mark Ellison <[email-masked]>
Date: Tue, 30 Nov 2021 17:03:13 -0500

Hello,

>From my perspective, there is no benefit in changing RFC text for the
AgentX protocol.  Organizations reacting to the presence of 'offensive
terminology' in AgentX now have another reason to adopt the NetConf
protocol, designed as the replacement for SNMP.  Of course, an organization
is free to decide which terms are used in its documentation- perhaps,
Executive Agent?  (note:  no Chief here ;-)

And, if the terminology in the RFC *were changed*, you'd be facing a term
mismatch between re-written RFCs and existing, running code.

Just my opinion.

Mark Ellison

On Tue, Nov 30, 2021 at 4:39 PM Randy Presuhn <
[email-masked]> wrote:

> > More generally, people really must take a more sophisticated approach to
> applying (legitimately) correct terminology. Words when used in reference
> to people and social contexts have a different import than when used in an
> inanimate domain context. People (and I mean all people) have legitimate
> concerns about offensive terminology in the human contexts ... those
> concerns really do not apply -- are not germane -- in many other contexts.
> I believe that most people inherently understand the distinction ... yes,
> there are some grey areas that need special consideration and we should do
> our best to exercise good judgment there (Internet protocols are not such
> an area) ... the easiest way out for unsophisticated people with megaphones
> of one form or another today is to ignore all distinctions and apply an
> embarrassingly simplistic blanket approach (that they are not embarrassed
> by such an approach is emblematic of their unsophisticated) ... alas, there
> are also certain "drivers" today -- e.g., social media "influencer"
> aspirations, mass media ratings aspirations, political power aspirations,
> and such -- that profitably foster, nurture, and exploit unsophisticated
> audiences ... these audiences are *not* dominated by people with the most
> valid concerns about offensive terminology in the human context.
> > </IMHO>
> >
> > BobN
> >
> > RFC 2741 (and its predecessors) have never used "slave", but instead
> have employed "subagent."  If the term "master agent" is problematic of
> itself, then SMUX (RFC 1227) and DPI (RFCs 1228 and 1592) specifications
> have the same issue.  A quick check shows that the major proprietary
> protocol in this space also retains the "master agent and subagent"
> terminology.
> >
> > Good luck finding people with the energy and motivation to find
> replacements for "master agent" and "subagent" and to update what in some
> cases are 30 year old documents.
> >
> > (particularly when consistently paired with a term like "subagent") is
> of itself objectionable.  If it is, the bad news is that I am not aware of
> any consensus regarding replacement terms in the subagent protocol space.
> >
> > This is *very* mature technology, and I suspect a lot of the people who
> have worked on it have either retired (like me) or long since gone on to
> other things, so document updates are probably in the realm of wishful
> thinking, unless you can recruit new people to do the work.
> >
> > Randy
> >

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 30 Nov 2021 14:27:34 -0800

Hi -

On 2021-11-30 2:03 PM, Mark Ellison wrote:
...
> protocol, designed as the replacement for SNMP.

A minor problem being that the NetConf work does not address the
issues that motivated the development of subagent technology,
and defines no interfaces between the NetConf Server and whatever
processes implement the instrumentation.

> Of course, an 
> organization is free to decide which terms are used in its 
> documentation- perhaps, Executive Agent?  (note:  no Chief here ;-)
> 
> And, if the terminology in the RFC *were changed*, you'd be facing a 
> term mismatch between re-written RFCs and existing, running code.

Yup.  I'd be willing to wager that the priority for updating that
code is *really* low on the priority list of whoever is taking
care of it these days.

Randy

---

From: Mark Ellison <[email-masked]>
Date: Tue, 30 Nov 2021 18:14:55 -0500

Hello,

> processes implement the instrumentation.

Yes, a valid point.  There are extensibility features in some of the
NetConf server development kits.  However, master- and sub-agent
terminology is used.  Since the NetConf WG has a clean slate wrt
extensibility and related terms, were it to take up extensibility as a
standard, less triggering terms would be in scope.

Mark Ellison