On 24/01/2008, Li Yun-w22793 wrote:
> I mean one object (let's assume the name is DUP) is defined in MOD1 and
> MOD2. Then MOD1 wants to refer the one defined in the MOD2 and MOD2 want
> to refer the one in the MOD1.

Then they need to have different names.

Within a given MIB module, *all* object names must be unique.
Both the objects defined within that MIB, and objects explicitly
IMPORTed. You can't have two objects with the same name,
both referenced in the same MIB.

> Hold moment. I think my assumption is avoiding the RFC standard, under
> this situation we will fall into this situation that there are two
> duplicate object name in one module, right?


> One more question about MIBS. If I set the MIBS as MY-MIB and MY-MIB
> refers the ifIndex from IF-MIB module. Mib2c will populate the IF-MIB

It will load the IF-MIB (and any other MIBs referenced in the IMPORT
clause). It will also load any MIBs referenced in the IMPORT clauses
of these other MIBs, and so on until it's got a fully consistent OID tree.

I don't know what you mean by "populating" the IF-MIB.

> (to get information about the ifIndex) for generate the stub function
> for MY-MIB, right? Based on my testing it seems we don't need to SET the
> MIBS as "MY-MIB IF-MIB". Could you please give me a clear picture?

Again, it's not really clear what you're asking here.
But I *think* you're asking whether it's necessary to explicitly list
all of the MIBs required (implicitly or explicitly) by your private MIB.

No - it's not. The MIB parsing library will load the IMPORTed MIBs

If that's not what you mean, then you will need to be a bit clearer.


This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Net-snmp-users mailing list
Please see the following page to unsubscribe or change other options: