> I am looking for the reason why sysUptime and snmpTrapOID variables are
> appended with a .0 instance in trap (notification) messages.

Because a value is always associated with an *instance* of a MIB object,
rather than the object itself.   This holds for both table column objects
(where there are typically many different instances) and scalar objects
(where there can be only one).
  The sole instance for a scalar object is always .0

>                                            I have not found any good 
> explanation for this in the SNMP related RFC's.

See RFC 1157 Section 3.2.6.3

>                                                    I remember to have read 
> somewhere that scalar objects must have a .0 as index but I don't know why.

So that scalar objects/instances work in the same way as tabular ones,
I believe.  It's inherently necessary to have some form of identifying
instance subidentifier(s) with a table, which automatically introduces
a distinction between the MIB object (as defined in the MIB file), and
the instances of that object (as reported by an agent).

A scalar object doesn't *need* to have an instance subidentifier in the
same way, but adding this .0 keeps the same object/instance distinction.

I suggest you look back through the early mailing list archives (if they're
available) for a more definitive description of why things were done this
way.   But they've been like that for over 15 years, so it's a little
late to change them now!

Dave



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Net-snmp-users mailing list
[EMAIL PROTECTED]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Reply via email to