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

[Juergen Schoenwaelder <[e-mail]>]

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:
> 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 }
> _______________________________________________
> MIB-DOCTORS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mib-doctors

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>