[MIB-DOCTORS] MIB question about renaming a textual convention

Norman Finn <nfinn@nfinnconsulting.com> Tue, 16 February 2021 19:07 UTC

Return-Path: <nfinn@nfinnconsulting.com>
X-Original-To: mib-doctors@ietfa.amsl.com
Delivered-To: mib-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08CA3A0E74 for <mib-doctors@ietfa.amsl.com>; Tue, 16 Feb 2021 11:07:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nfinnconsulting.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 t21eHuxbusJR for <mib-doctors@ietfa.amsl.com>; Tue, 16 Feb 2021 11:07:08 -0800 (PST)
Received: from us2-ob3-7.mailhostbox.com (us2-ob3-7.mailhostbox.com [208.91.199.220]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA553A0E73 for <mib-doctors@ietf.org>; Tue, 16 Feb 2021 11:07:08 -0800 (PST)
Received: from [10.0.0.2] (99-117-116-219.lightspeed.sndgca.sbcglobal.net [99.117.116.219]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nfinn@nfinnconsulting.com) by us2.outbound.mailhostbox.com (Postfix) with ESMTPSA id 64D7AD8098; Tue, 16 Feb 2021 19:06:55 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nfinnconsulting.com; s=20161121; t=1613502415; bh=tsPuJJlEdV9cpv8CFgyO1rr/5jsZbMrzxhhOmlGa9nU=; h=From:Subject:Date:Cc:To; b=UIqjnPajVCXjlOO2v9T4n8AS3CB/N0JSUCWcQ8fMHJ8jOgwdZVhd7njiOPmEhmuY5 AA5Z9NqJ5K9RsQ5zF6ClIqJawjmnrvlZ6PsU0zeib7yj7Zd5Ix5Um/USMhYwG61BOC YrIMMK1tDoNoDs6CdKwClDO34FUEhbPOknZRHzHM=
From: Norman Finn <nfinn@nfinnconsulting.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Message-Id: <90D6E207-0024-4616-B303-7DA6049F57E9@nfinnconsulting.com>
Date: Tue, 16 Feb 2021 11:06:54 -0800
Cc: Paul Congdon <paul.congdon@tallac.com>
To: mib-doctors@ietf.org
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-CMAE-Score: 0
X-CMAE-Analysis: v=2.3 cv=R5t95uZX c=1 sm=1 tr=0 a=aTmnyjqu01k1Du4yLKcxzA==:117 a=aTmnyjqu01k1Du4yLKcxzA==:17 a=kj9zAlcOel0A:10 a=CUCBtFd6CSUzH5bkqiYA:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=CjuIK1q_8ugA:10
Archived-At: <https://mailarchive.ietf.org/arch/msg/mib-doctors/EFuOG34Ogicx7Hf14YfrhvkXLS8>
Subject: [MIB-DOCTORS] MIB question about renaming a textual convention
X-BeenThere: mib-doctors@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: MIB Doctors list <mib-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mib-doctors/>
List-Post: <mailto:mib-doctors@ietf.org>
List-Help: <mailto:mib-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mib-doctors>, <mailto:mib-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Feb 2021 19:07:11 -0000

I'm asking this question on behalf of IEEE 802.1.

We have a textual convention (IEEE8021PriorityCodePoint, in IEEE8021-TC-MIB) with a correct SYNTAX and a correct DESCRIPTION, but with an unfortunately misleading name.  This TC is used correctly in a number of MIBs, but its name is a continuing source of trouble when it is used incorrectly in new MIBs.

Our current plan is to define a new TC, IEEE8021PriortyMapping, with exactly the same SYNTAX (a set of enumerated values) and DESCRIPTION sections, for the use of new MIBs, and deprecate the use of IEEE8021PriorityCodePoint.  Questions:

1. If we revise the existing objects that use SYNTAX IEEE8021PriorityCodePoint (correctly) to use IEEE8021PriortyMapping, instead, would that require deprecating the those objects and defining new ones?  Remember that both TCs have exactly the same SYNTAX and DESCRIPTION.

2. Can you actually deprecate a TC?

3. Is there a better way to do this?  For example, it we should really deprecate the old variables in order to use the new TC, we would just leave them alone.

Thanks in advance for your advice.

-- Norm

SNIPPET 1:  The misnamed TC (IEEE 802.1Q 2019 edition, clause 17.7.1, IEEE8021-TC-MIB)

IEEE8021PriorityCodePoint ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Bridge ports may encode or decode the PCP value of the
frames that traverse the port. This textual convention
names the possible encoding and decoding schemes that
the port may use. The priority and drop_eligible
parameters are encoded in the Priority Code Point (PCP)
field of the VLAN tag using the Priority Code Point
Encoding Table for the Port, and they are decoded from
the PCP using the Priority Code Point Decoding Table."
REFERENCE "
12.6.2.6
"
SYNTAX INTEGER {
codePoint8p0d(1),
codePoint7p1d(2),
codePoint6p2d(3),
codePoint5p3d(4)
}

SNIPPET 2: A typical proper use (IEEE 802.1Q 2019 edition, clause 17.7.2, IEEE8021-BRIDGE-MIB):

ieee8021BridgePortPriorityCodePointSelection OBJECT-TYPE
SYNTAX IEEE8021PriorityCodePoint
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object identifies the rows in the PCP encoding and
decoding tables that are used to remark frames on this
port if this remarking is enabled."
REFERENCE "
12.6.2.6
,
12.6.2.7
"
::= { ieee8021BridgePortPriorityEntry 3 }