HI,

this is quick - got to run, but consider:

with ::= { goo foo(1) }

can you import foo in another MIB module (answer NO)

Also, what do you do with the following: foo OBJECT IDENTIFIER ::= { goo 1 } bar OBJECT IDENTIFIER ::= { goo 1 } soo OBJECT-TYPE ... ::= { goo 1 }

Hint: it's legal.

Regards, /david t. perkins

On Tue, 30 Nov 2004, [ISO-8859-1] Frank Strau� wrote:

David T. Perkins wrote:

...

The message below is not correct. That is, it is not a warning situtuation and the term "object identifier" is not at all appropriate.

I suggest the folloing text, if you still want to emit this bogus warning.

So, for bar OBJECT-TYPE .... ::= { gar foo(3) } and soo OBJECT-TYPE .... ::= { gar foo(4) }

Emit the following messages: ./XXX-MIB:165: warning: local label "foo" used for OID value of "soo" has been previously used with a different sub-identifier value ./XXX-MIB:40: info: previous definition of `snmpDot3MauMgt'

...

From my point of view, the messages currently implemented and quoted below are

more precisely describing the facts: such labels always refer to a complete OID (derived from a subid and a prefix), hence I don't like the term "used with a different sub-identifier value". E.g. in the following example, it would be misleading to refer to a sub-identifier instead of an OID, because the sub-identifier is the same (3) but a warning should be raised because the OID is different (gar.1.3 vs. gar.3):

bar OBJECT-TPYE ... := { gar boo(1) foo(3) } soo OBJECT-TPYE ... := { gar foo(3) }

...

But again, the above is NOT illegal and it is fine to have the following OID values: ::= { gar foo(1) foo(2) bar(3) bar(4) } ... ::= { gar bar(1) guw(2) foo(3) foo(4) } ... ::= { gar foo(2) } ... ::= { gar bar(2) } etc

Ack. That's why we emit a warning, not an error. We had already this discussion for several other warnings on the libsmi mailinglist. People, who only want to know whether a MIB module is formally and syntactically correct (without any additional "hints"), should use the "-l" option to set the threshold level of displayed messages.

...

On Tue, 30 Nov 2004, [ISO-8859-1] Frank Strau� wrote:

...

Thanks to all who contributed to this issue. I've just comitted a new revision to the libsmi SVN repository that handles OID and identifiers in the "NameAndNumberForm" more acurately, and also emits warnings such as...

./XXX-MIB:165: warning: object identifier for label `snmpDot3MauMgt' does not match previous label usage ./XXX-MIB:40: info: previous definition of `snmpDot3MauMgt'

./XXX-MIB:165: warning: label `snmpDot3MauMgtXXX' does not match previous label `snmpDot3MauMgt' for same object identifier ./XXX-MIB:40: info: previous definition of `snmpDot3MauMgt'

-- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust !! your settings, send a mail message to libsmi-request@ibr.cs.tu-bs.de !! or look at https://www.ibr.cs.tu-bs.de/mailman/listinfo/libsmi.

David T. Perkins wrote:

...

Also, what do you do with the following: foo OBJECT IDENTIFIER ::= { goo 1 } bar OBJECT IDENTIFIER ::= { goo 1 } soo OBJECT-TYPE ... ::= { goo 1 }

Would I ask why it is legal ? Any statements in the rfc 2578 or other rfc to back up the claim ?

thanks, Daniel

...

Hint: it's legal.

HI,

This recent discussion about valid OID values is quite old and has been repeated many times on many different forums.

RFC 2578, section 3.6 has the most direct text. However, it does not specificly address "named-number" sub-identifiers in OID values, nor discuss the issue of uniqueness of descriptors of sibling OID values.

It explicitly covers: 1) registration vs assignment and says that it is legal. That is, in a MIB module, one could have all three of the following definitions (which all have the same OID value):

d1 OBJECT IDENTIFIER ::= { goo 1 } d2 OBJECT IDENTIFIER ::= { goo 1 } d3 OBJECT-IDENTITY -- or OBJECT-TYPE, MODULE-COMPLIANCE, etc ::= { goo 1 }

It does not say anything about labels. And in such cases, one has to read the ASN.1-1988 definition. So for cases: 2) semantics of a label on a "name-number" sub-identifier. For ASN.1, the lalel caries no semantics and is simply an aid to the reader. Thus, you have the following outcomes: a) the label is just a label, and even though it seems redundant or conflicting, it can be specified on the last sub-identifier in an OID value. Thus, the following definitions are legal: da1 OBJECT IDENTIFIER ::= { goo da1(1) } -- legal and "redundant" label da2 OBJECT IDENTIFIER ::= { goo da2X(1) } -- legal and "conflicting" label b) the label cannot be referenced by other definitions. Thus, the second definition is illegal: db1 OBJECT IDENTIFIER ::= { goo bar(1) } db2 OBJECT IDENTIFIER ::= { bar 1 } -- illegal, since bar is not defined! c) the label cannot be imported! Thus, the following import of "regs" is illegal: M1 DEFINITIONS ::= BEGIN ... dc1 OBJECT IDENTIFIER ::= { myRoot regs(1) 34 } ... END M2 DEFINITIONS ::= BEGIN IMPORTS regs FROM M1 -- illegal, since regs is not defined ... END d) the label can be used on other values (even though it may be confusing). Thus the second usage (in the same MIB module) is legal: dd1 OBJECT IDENTITY ::= { goo bar(1) } dd2 OBJECT IDENTITY ::= { goo bar(2) } -- legal A case that is not covered (that I can find) in the ASN.1-1988 docs or in the SMI is the following: 3) The same descriptor on sibling OID values for either registrations or assignments. Note that ASN.1 (and the SMI) disallows the same descriptor to be used on a definition within a single MIB module. However, both (in certain cases) allow the same descriptor to be used on definitions found in different MIB modules. Normally this is not a problem. However, if the descriptor are used for "sibling OID values", then this is confusing. For example, I can find no text that restricts the following definitions: M3a DEFINITIONS ::= BEGIN ... def3 OBJECT-IDENTITY ... ::= { goo 1 } ... END M3b DEFINITIONS ::= BEGIN ... def3 OBJECT IDENTIFIER ... ::= { goo 2 } END M3c DEFINITIONS ::= BEGIN ... def3 OBJECT-TYPE ... ::= { goo 3} ... END Resulting in defintions: goo.1 def3 goo.2 def3 goo.3 def3 I suggest that the above be made illegal, and clarified in an update to RFC 2578. That is, is is illegal to create definitions that are assignments and registrations that use the same descriptor for "OID value siblings".

And a repeat of a usage that comes up again and again. 4) What is the legal form or OID values? The ASN.1 spec and the SMI must be consulted to determine the rules. The important rules are: a) an OID value is contained in "{" and "}" b) the first item is either: i) a previous defined (or imported) item that has an OID value ii) a number or named-number with value of 0, 1, or 2 iii) one of the following well known names: ccitt, iso, joint-iso-ccitt (see RFC 2578 section 3.5) c) the minimum number of items specified in the "{" and "}" is not explicited stated in the SMI, and is allowed to be 1 in ASN.1. However, one does not seem to be supported by SNMP MIB module compilers. (Do we need clarification?) The SMI restrict the maximum number to 128. (However, practically it would be lower if the first item is a defined item with an OID value.) That is, the following are legal: d4a OBJECT IDENTIFIER ::= { goo 1 2 3 } d4b OBJECT IDENTIFIER ::= { goo bar(2) 78 red(3) 99 } d) there is no requirement that all of the OID sub-identifiers in an OID value have an assignment, registration, or label associated with them. So, an OID value dump could look like: iso(1).org(3).dod(6).internet(1).678.docs(1).foo(2) That is, the sub-identifier "678" does not have a descriptor or label associated with it!

I hope I have covered this issue. If not, others please send questions and examples. Maybe there needs to be a two or three page BCP for OIDs in SNMP MIB modules.

Regards, /david t. perkins