IETF Logo Mail Archive

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

Joshua Bennetone <jbenneto@us.ibm.com> Tue, 30 November 2021 19:03 UTC

Return-Path: <jbenneto@us.ibm.com>
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 04D473A1503 for <ietfmibs@ietfa.amsl.com>; Tue, 30 Nov 2021 11:03:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ibm.com
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 t1I-TRlcp8YY for <ietfmibs@ietfa.amsl.com>; Tue, 30 Nov 2021 11:03:08 -0800 (PST)
Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B7143A151A for <ietfmibs@ietf.org>; Tue, 30 Nov 2021 11:03:06 -0800 (PST)
Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1AUIml38003622 for <ietfmibs@ietf.org>; Tue, 30 Nov 2021 19:03:05 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=mime-version : subject : to : message-id : from : date : content-type; s=pp1; bh=FBxL/L3xqY6EuUdcEd+sMlYva368Lh+cvFxM56qUHQg=; b=HO30Hj6u5+x7ylBgO26v6CcbpQXQJV8NwH0WZw3ddNJS1JmkyU50/Kbe7+MOmZZSVSZB wmQj1TL13xwwD22QowOIOisQGS5lKG1GQynOIyh/aMp1FyCGV0B5sEd/Umdti58oK8eb KfQFWkDoRBohLvcYShH/o/Rx5mZ8+I6x3e7yW3fpmZK7FpQB9mwJE5if7YgjgKgdYDC2 9jp5C642f/Vta4u0Ecwj8k2Cetpk74ci/KlBIhkF1hZb57BbDWt9OYigvYEw3XSUw7dv IOtEgr7/8cakLwwQcI9FZHzXbCE58bRi432RPMhzqhlIKObBBckVjoxapsgArW34aE1z YA==
Received: from ppma01wdc.us.ibm.com (fd.55.37a9.ip4.static.sl-reverse.com [169.55.85.253]) by mx0b-001b2d01.pphosted.com with ESMTP id 3cnsjg09hh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <ietfmibs@ietf.org>; Tue, 30 Nov 2021 19:03:04 +0000
Received: from pps.filterd (ppma01wdc.us.ibm.com [127.0.0.1]) by ppma01wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 1AUIbZdp017287 for <ietfmibs@ietf.org>; Tue, 30 Nov 2021 19:03:03 GMT
Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by ppma01wdc.us.ibm.com with ESMTP id 3ckcab3cyu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <ietfmibs@ietf.org>; Tue, 30 Nov 2021 19:03:03 +0000
Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp22035.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1AUJ32YC43974972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <ietfmibs@ietf.org>; Tue, 30 Nov 2021 19:03:02 GMT
Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A5425112062 for <ietfmibs@ietf.org>; Tue, 30 Nov 2021 19:03:02 +0000 (GMT)
Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 82FE8112066 for <ietfmibs@ietf.org>; Tue, 30 Nov 2021 19:03:02 +0000 (GMT)
Received: from mww0091.wdc07m.mail.ibm.com (unknown [9.208.69.236]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTPS for <ietfmibs@ietf.org>; Tue, 30 Nov 2021 19:03:02 +0000 (GMT)
MIME-Version: 1.0
To: ietfmibs@ietf.org
Message-ID: <OF9F597A9A.90F9B174-ON8525879D.0066FDB2-8525879D.0068A4A9@ibm.com>
From: Joshua Bennetone <jbenneto@us.ibm.com>
Date: Tue, 30 Nov 2021 15:02:58 -0400
Content-type: multipart/alternative; Boundary="0__=0ABB0D0EDFF57B228f9e8a93df938690918c0ABB0D0EDFF57B22"
Content-Disposition: inline
X-KeepSent: 9F597A9A:90F9B174-8525879D:0066FDB2; name=$KeepSent; type=4
X-Mailer: HCL Notes Build V1101FP3_03312021 SHF15 May 21, 2021
X-Disclaimed: 57295
X-MIMETrack: CD-MIME by Router on MWW0091/01/M/IBM at 11/30/2021 19:03:02, CD-MIME complete at 11/30/2021 19:03:02,Itemize by Router on MWW0091/01/M/IBM at 11/30/2021 19:03:02
X-TM-AS-GCONF: 00
X-Proofpoint-GUID: V0wg6U1-c_4sU5QaW_5-_VF-Jawcc3mA
X-Proofpoint-ORIG-GUID: V0wg6U1-c_4sU5QaW_5-_VF-Jawcc3mA
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-11-30_10,2021-11-28_01,2020-04-07_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 priorityscore=1501 malwarescore=0 clxscore=1011 phishscore=0 adultscore=0 bulkscore=0 lowpriorityscore=0 mlxlogscore=487 spamscore=0 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2111300097
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietfmibs/hdRMrMKnqt271I3V1A4-3o3lR5k>
Subject: [IETFMIBS] 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 19:19:10 -0000


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

v2.23.0 | Report a Bug | By Email