[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: HOST-RESOURCES-MIB and the hrSWInstalledID object




Alexander,

I'll give more background below but the bottom line is that the object you are looking for already exists: hrSWInstalledName -> it is supposed to contain the manufacturer, name and version encoded as an InternationalDisplayString. As for productID, if I was in your shoes I'd set it to 0.0 for many entries but it'd be cool to create real values for the OS version and important software like sendmail.

The motivation behind the productID was to enable computer programs (as opposed to humans) to parse product and version info to enable automation (sometimes a program needs to know vendor, product and version to know what to do). Unfortunately strings are useful for humans but often problematic for computers because of different capitalization, spelling, abbreviations, punctuation, etc. And productID was conceived in the early 90's before Internationalization was a big topic, which adds language and character sets into the mix of problems.

That said, strings were very useful and in wide use for interpretation by humans (and some programs) and given the registration burden of productID's it wasn't really clear how widely they would be used. So we decided to use both since each has benefits that can't be provided by the other.

Anyway, the idea was that every piece of software and hardware would have a string object (e.g. hrSWInstalledName) and a productID object (e.g. hrSWInstalledID). Since strings are more readily available it was assumed that just about everything would have strings populated and over time more and more things could have productID's registered, presumably starting with those things where the cost/benefit ratio was the best (OS versions having a lower cost and a higher benefit than, say some Solitare game I downloaded).

Regards,
Steve

On 3/29/2005 1:31 PM, Alexander W. Janssen wrote:

Steven,

sorry to bug you with this comment, you are mentionend in the
HOST-RESOURCES-MIB as the responsible contact.

I hope i am addressing the right person for this subject, if not, it would be
nice if you could forward this email to the right WG, since the "IETF Host
Resources MIB Working Group", which is mentioned in the MIB, does not seem to
exist any more.

Maybe my whole request/complaint is out of date or even redundant, but i
wanted to give my feedback anyway.

There is some aspect of the HOST-RESOURCES-MIB really chewing on me.

I am just extending the NET-SNMP daemon, especially the hrSWInstalled tree of
the HOST-RESOURCES-MIB, for a specific Linux-Distribution which is not
supported yet by this daemon.

However, i stumbled over the "uselesness" of the hrSWInstalledID-Object. It is
used to give out the version of the installed software-package.

My problem is that it allways implies that the distributor maintains his
Enterprise-MIB-space and extends it every time a new software-package is
included.

As you can imagine, this doesn't make sense in most cases - with no UNIX, no
Windows, no Linux, no nothing. Well, maybe Cisco likes to do that, but in
general it is very unpractical since nobody is going to replace his MIBs just
because "Foobar Inc." in Southwest-Kickass, Greenland, released version
3.1.4.22-rc4-beta of their software-package "Fridgecontrol".
Every vendor seems to set it to SNMPv2-SMI::zeroDotZero - i don't know about
their motivation, but i think they have the same idea like me.

I wanted to know if there are any plans to *replace* the variable in the
hrSWInstalledID-Object (currently ProductID which points to the
Enterprise-space of a vendor) with something useful, like an IA5 String? I
could easily set this string to the current version of the software-package if
it would be IA5 or something else.

I know, i am just one in a million SNMP-users, but it would be really nice if
you could bring up this topic if a 2790bis is being considered. I know that
someone just can't change a MIB - there is too much depending on it - but the
dependencies should be *really* in the minority this time.

Thanks a lot for your time,
sincerely, Alexander Janssen.