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

Randy Presuhn <randy_presuhn@alumni.stanford.edu> Tue, 30 November 2021 21:39 UTC

Return-Path: <randy_presuhn@alumni.stanford.edu>
X-Original-To: ietfmibs@ietfa.amsl.com
Delivered-To: ietfmibs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E652D3A15BC for <ietfmibs@ietfa.amsl.com>; Tue, 30 Nov 2021 13:39:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.749
X-Spam-Level:
X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkFcsKzIkjG5 for <ietfmibs@ietfa.amsl.com>; Tue, 30 Nov 2021 13:39:22 -0800 (PST)
Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422CB3A15BD for <ietfmibs@ietf.org>; Tue, 30 Nov 2021 13:39:22 -0800 (PST)
Received: by mail-pg1-f169.google.com with SMTP id r5so21222542pgi.6 for <ietfmibs@ietf.org>; Tue, 30 Nov 2021 13:39:22 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=2sgckMN4piosjjoAUTjmMpOKtNhTEAf3wCn/cWH7MFM=; b=ZFd2foQ4r8d8PToKX2vDrPgTsI8fBrUspwHLkS16BMT+X/nK0IDoZD3+VjuM0D9f+N ecrKPi64SdPHYE/QIKyAEVvzAQHKmS0RaiYXhSnJ3KjuCu9ggTgbwC/idiZ4K0cb1OWm I7qHI+csjOUn8YTvMFxR9LIn4mxlyOlTZjV/BVKxYsDyPpXZVdZQXEjhz0rT9qWp8jFH Pd+B08Owo9P9skOCEhA7+LkUCNN9NMmMXIKV1Kb3p+uNxfR5AK2ibsR2Rz9WE1jLfmll HlykS/nr0UmL03KgVODqqmKpDfjvtrK7fbc1W8a7v4lfjdcAs+WVVypJnb92WeK/GEuK O01A==
X-Gm-Message-State: AOAM532f+84jPzAD3fEwrXY3b80dpG65Ys7iTgNJf8vDRvaMuEUkseyQ EgIysaIzQFqUmgDc+mCepgWGx5/K3wrtrw==
X-Google-Smtp-Source: ABdhPJxy/vx71JN7b1/o4Rj/46K5xhQMqwnubXeepG4pPXF+I1XavDGvwZ8F2dF3RIt7lszkygI51g==
X-Received: by 2002:a05:6a00:1584:b0:49f:e5dd:f904 with SMTP id u4-20020a056a00158400b0049fe5ddf904mr1594680pfk.55.1638308361746; Tue, 30 Nov 2021 13:39:21 -0800 (PST)
Received: from ?IPV6:2601:646:9300:112b:d9a9:d437:ba4d:8e78? ([2601:646:9300:112b:d9a9:d437:ba4d:8e78]) by smtp.gmail.com with ESMTPSA id b8sm3669814pfr.213.2021.11.30.13.39.21 for <ietfmibs@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Nov 2021 13:39:21 -0800 (PST)
Message-ID: <cdb2366e-577d-9cbd-d6ed-cfa32662c038@alumni.stanford.edu>
Date: Tue, 30 Nov 2021 13:39:20 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2
Content-Language: en-US
To: ietfmibs@ietf.org
References: <OF9F597A9A.90F9B174-ON8525879D.0066FDB2-8525879D.0068A4A9@ibm.com> <31840_1638302237_61A6821B_31840_442_1_3c6281a7-69f1-2b08-0189-b023ae7c85ee@alumni.stanford.edu> <MN2PR09MB471664A0568446DA77AE0CCFA8679@MN2PR09MB4716.namprd09.prod.outlook.com>
From: Randy Presuhn <randy_presuhn@alumni.stanford.edu>
In-Reply-To: <MN2PR09MB471664A0568446DA77AE0CCFA8679@MN2PR09MB4716.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietfmibs/Fcpmqhbju6AjOhvvVmUt9Jl5H4c>
Subject: Re: [IETFMIBS] [EXT] Re: Issues with master/slave terminology in SNMP and FDDI MIBs
X-BeenThere: ietfmibs@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF MIB Discussion list <ietfmibs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietfmibs>, <mailto:ietfmibs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietfmibs/>
List-Post: <mailto:ietfmibs@ietf.org>
List-Help: <mailto:ietfmibs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietfmibs>, <mailto:ietfmibs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Nov 2021 21:39:27 -0000

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

On 2021-11-30 12:53 PM, Bob Natale wrote:
> +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 <ietfmibs-bounces@ietf.org> On Behalf Of Randy Presuhn
> Sent: Tuesday, November 30, 2021 2:57 PM
> To: ietfmibs@ietf.org
> 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.
> 
>> 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
> 
> _______________________________________________
> IETFMIBS mailing list
> IETFMIBS@ietf.org
> https://www.ietf.org/mailman/listinfo/ietfmibs
> _______________________________________________
> IETFMIBS mailing list
> IETFMIBS@ietf.org
> https://www.ietf.org/mailman/listinfo/ietfmibs
>