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

From: Norman Finn <[email-masked]>
Date: Tue, 16 Feb 2021 11:06:54 -0800

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 }

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Feb 2021 20:24:25 +0100

Dear Norm,

since a TC has a status clause, you can of course deprecate it. This
may trigger warnings on modules that use the TC (and which had no
warnings before).

Is it possible replace a TC with a different one without changing the
OID of an object? I think so as long as the syntax and semantics are
identical. Section 10.2 of RFC 2578 spells out the case of replacing
the value of a SYNTAX clause with a TC and it says its OK as long as
syntax and semantics are the same. There are not really any side
effects since the "type" definition used in an object definition is
not externally visible/accessible.

To sum up: What you are proposing appears to be legal from the SMIv2
perspective. Whether its worth the effort is something I can't judge.
Such a change likely takes years to propagate, in the IETF it would
take decades to infinity. So you will have to make a judgement call
how widely the TC is used and what the update paths of affected
documents will be.

/js

On Tue, Feb 16, 2021 at 11:06:54AM -0800, Norman Finn wrote:
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>