> I believe that the logical outcome for registering three single objects
> should be three ranges N::N, not N::N+1.
> 
> e.g., I would believe that these would be correct:
> 
>   1.3.6.1.3.4 - 1.3.6.1.3.4
>   1.3.6.1.3.5 - 1.3.6.1.3.5
>   1.3.6.1.3.6 - 1.3.6.1.3.6
> 
> 
> Is there some other knowledge that applies ?


Question - are you talking about registering threee MIB instances,
or three MIB (scalar) objects?

When registering a single instance  (e.g. sysDescr.0), then I'd
agree - this should ideally register a single OID - i.e. the "range"
        [ .1.3.6.1.2.1.1.1.0 - .1.3.6.1.2.1.1.1.0 ]

But when registering a MIB scalar object (e.g. sysDescr), then this
needs to register a full subtree - i.e. the range
        [ .1.3.6.1.2.1.1.1   - .1.3.6.1.2.1.1.2   )

[Note that this is the mathematical notation for
        "everything up to but not including" ]


That's because the handler for sysDescr would need to catch both
valid instances (.1.3.6.1.2.1.1.1.0) and invalid instances
(.1.3.6.1.2.1.1.1,  .1.3.6.1.2.1.1.1.99,  .1.3.6.1.2.1.1.1.0.1.2.3, etc)
And the situation for registering a table, or a full subtree is the
same (but more so).


When the agent MIB registry was first developed, this was done for
the v4 module API, which worked only with subtrees (containing a list
of named MIB objects).   At that point, there was no concept of
registering individual instances.
   Things have moved on a bit since then. but I'm not convinced that
the agent registry has been reworked to include the special processing
that would be necessary for individual instance registrations.
So in the meantime, treating an instance registration as a subtree
would work properly in 99% of cases - albeit with some unnecessary
processing.


Dave



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
_______________________________________________
Net-snmp-coders mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

Reply via email to