对象名称/描述符在SNMP MIB模块中必须唯一吗？

Question

我有一个供应商提供的MIB文件，其中在同一MIB的两个不同表中定义了相同的对象名称/描述符。不幸的是，我认为MIB是专有的，不能完整地在此处发布。因此，我创建了一个类似的示例Foobar.mib文件，该文件已包含在本文的结尾。

我的问题是：这种MIB是否有任何合法或可以被视为有效的方法？

Net :: SNMP可以打印它的树，它看起来像这样：

+--foobar(12345678)
   |
   +--foo(1)
   |  |
   |  +--fooTable(1)
   |     |
   |     +--fooEntry(1)
   |        |  Index: fooIndex
   |        |
   |        +-- -R-- INTEGER   fooIndex(1)
   |        +-- -R-- String    commonName(2)
   |
   +--bar(2)
      |
      +--barTable(1)
         |
         +--barEntry(1)
            |  Index: barIndex
            |
            +-- -R-- INTEGER   barIndex(1)
            +-- -R-- String    commonName(2)

现在注意，commonName在fooTable和barTable下都定义了非常相同的MIB（请​​参见下面的示例Foobar.mib）。

这混淆了Net :: SNMP，因为FooBarMib::commonName现在可以表示两个不同的OID。

很高兴在供应商的错误报告中包含指向RFC的链接。

我发现RFC 1155 - Structure and identification of management information for TCP/IP-based internets说：

与每个对象类型相对应的对象类型互联网标准的MIB应该是唯一但可记忆的，可打印的串。这促进了人类使用通用语言时讨论MIB，还有助于简化简单的表映射用户界面。

这仅适用于“互联网标准MIB”，因此不适用于供应商MIB吗？

我也发现RFC 2578 - Structure of Management Information Version 2 (SMIv2)表示：

对于出现在信息模块中的所有描述符，描述符应是唯一且易记的，并且长度不得超过64个字符。

但是SNMP v1代理的MIB是否也必须遵守RFC 2578？ SNMP代理无论出于何种原因，实现MIB都仅支持SNMP v1。和RFC2578的标题为SMIv2，2令我有些担心。但是，MIB本身确实是从SMIv2 FWIW导入的。

我发现有两个Internet参考，其中说对象名称/描述符在MIB中必须是唯一的，但没有源参考：

Andrew Komiagin in "SNMP OID with non-unique node names"在SO上这样说：

MIB对象名称必须唯一在整个MIB文件中。

[Dave Shield on the Net::SNMP mailing list说：

在给定的MIB模块中，所有对象名称必须唯一。该MIB中定义的对象和显式对象导入。您不能有两个名称相同的对象，两者都在同一个MIB中引用。

我很乐意为这两个等效语句中的任何一个获取标准/ RFC参考。

样本Foobar.mib

[这将commonName定义为::={ fooEntry 2 }，并且进一步向下定义为::={ barEntry 2 }：

-- I've changed the MIB module name.
FooBarMib DEFINITIONS ::= BEGIN

IMPORTS sysName, sysLocation FROM SNMPv2-MIB;
IMPORTS enterprises, OBJECT-TYPE FROM SNMPv2-SMI;

-- I've provided a fake name and enterprise ID here

foobar OBJECT IDENTIFIER::= {enterprises 12345678}

foo OBJECT IDENTIFIER::={ foobar 1 }

fooTable OBJECT-TYPE
        SYNTAX SEQUENCE OF FooEntry
        MAX-ACCESS not-accessible
        STATUS current
::={ foo 1 }

fooEntry OBJECT-TYPE
        SYNTAX FooEntry
        MAX-ACCESS not-accessible
        STATUS current
        INDEX { fooIndex }
::={ fooTable 1 }

FooEntry ::= SEQUENCE{
        fooIndex INTEGER,
        commonName OCTET STRING,
        -- other leaves omitted
}

fooIndex OBJECT-TYPE
        SYNTAX INTEGER
        MAX-ACCESS read-only
        STATUS current
::={ fooEntry 1 }

commonName OBJECT-TYPE
        SYNTAX OCTET STRING
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
        "Label for the commonEntry"
::={ fooEntry 2 }

bar OBJECT IDENTIFIER::={ foobar 2 }

barTable OBJECT-TYPE
        SYNTAX SEQUENCE OF BarEntry
        MAX-ACCESS not-accessible
        STATUS current
::={ bar 1 }

barEntry OBJECT-TYPE
        SYNTAX BarEntry
        MAX-ACCESS not-accessible
        STATUS current
        INDEX { barIndex }
::={ barTable 1 }

BarEntry ::= SEQUENCE{
        barIndex INTEGER,
        commonName OCTET STRING,
        -- other leaves omitted
}

barIndex OBJECT-TYPE
        SYNTAX INTEGER
        MAX-ACCESS read-only
        STATUS current
::={ barEntry 1 }

commonName OBJECT-TYPE
        SYNTAX OCTET STRING
        MAX-ACCESS read-only
        STATUS current
        DESCRIPTION
        "Label for the commonEntry"
::={ barEntry 2 }

END

Answer 1

不幸的是，企业可以做他们想做的任何事情。如果他们想打得很好，建议他们遵守规则。 https://tools.ietf.org/html/rfc2578#section-3的详细信息>