Hello,
I have a general net-snmp question. We are implementing a kind of 'generic' MIB, to be used by 'generic' NMSs. The general structure of the MIB is a table of NEs (Network Elements), each has its own unique name, and then a table of MOs (Manageable Objects) of each NE.
We are considering 2 alternatives:

1. The access to the MO table will be carried via a net-snmp contextName determines by the NE's name. i.e. the index of the MO table will only be its ID (MO ID, a integer), while having to create and register to each MOs table a contextName.

2. The access to the MO table will take place via a index which is a bit more complex (NE ID, MO ID, both are integers)

Thanks,
Gonen

Gonen,

Did you have a question?
I'm not a fan of random folks just deciding to re-write underlying environmental structure because they decided it looked like a thing they'd like to do. Oddly enough, the rest of us invariably don't share that feeling, however, if you have a question, we do answer those.

Dijetlo,

I can't remember a rude response like yours,frankly.
Yes, I have a question, and it was stated very clear, the need to choose between 2 coding options, why don't you just anser it if you can contribute ?

TRhanks,
Gonen

That actually has more to do with your memory than my response.

OK.
Don't waste the time.

The fact that MIBs are named in a non-intuitive manner is really only a problem for noobs who haven't figured out that you don't have to remember the MIB addresses, you can load them in a spread sheet and reference them that way.
Honestly Gonen. If all you're doing is renaming MIBs, why bother?

I been writing SW for almost 30 years, at least some of it around snmp.
The new stuff for me here is using contextName, I'm implementing this specific MIB using mib2c, and it seems that things tend to be complicated when a table is accessed using a contextName.
Therefore I'm considering if it worth using a bit more complex index to the table rather than a contextName.

Can you help with that?

Thanks,
Gonen

Probably, since I've worked with networks, servers and SNMP as long as you've been developing software.
However, my suggestion remains the same.
I think the point your missing here, Gong, probably because you are a developer and not an engineer, is in the world of the engineer, most people don't ever see the MIB name, much less the table designation for the MIB. What they see is a little red ball lighting up on their monitor beside a server name. I have to figure out exactly why, so I have to know the OID/MIB designation, but in a staff of a hundred plus folks, there aren't 10 who even realize that what makes the red ball light up is an snmp trap popping on the server.
What I'm saying is you can do it, it's certainly not hard to come up with a naming convention less counter-intuitive than the one UC Davis picked but to what end? A LOT of software relies on the SNMP OID/MIB structure remaining relatively unchanged.
Besides, the naming convention is not the primary problem with SNMP ( for my money, if you want to fix SNMP, figure out a way around the connection less nature of the SNMP trap alert)