On Mon, Feb 18, 2013 at 10:43 AM, Patricia Chocan Fernandez <
patricia.chocanfernan...@newtec.eu> wrote:
>
> Dear Mr. Hew,
>
> thanks for your fast answer.
> In my opinion, using a "not-applicable" value is the best option.
>
> Nevertheless, I am a bit doubtful regarding the options:
>
> - Should we return a noSuchObject error, and act like
> the object is temporarily not implemented?
> - Should we return a noSuchInstance error?
>
> The information that I have found in the Rfc's is not very clear
> in this respect.
>
> As stated, returning a 'noSuchObject' should
> only be done when the object is "not implemented", and they clearly
> make the difference between "implementation" and "runtime" behavior.
> Besides, they state that an implemented 'scalar' object contains always
> 'one instance'
> (not "zero or one"). Following this line of thinking, it would be
> unacceptable
> to return a noSuchObject/noSuchInstance error.
>
> However, we could also think that a device "implements" a SNMP object
> only under certain configurations. In this case, it would acceptable
> (and even desirable) to return a noSuchObject/noSuchInstance error.
>
> What is your opinion in this matter?
>
Those are really used only is something is not implemented or is missing
Ie. not-supported, not-loaded, not-running...
Ie. A noSuchObject should be returned whenever something that doesn't
exist is queried. For instance... querying a Cisco variable on a non-Cisco
box. You could extend that concept to querying an xyz MIB on a box
that doesn't support 'xyz'. But when it comes closer to the details, like
querying the abc variable in the 'xyz' MIB, then you have to ask youself...
'what do I want the querying application to think' ... is happening.
Ie. There are two facets of MIB implementations:
1/ From the device being managed,
2/ The NMS or management application being used to perform the management.
And for your question... its #2 that you need to answer first...
to understand how you want to address your dilema.
If you are in control of both ends of the management chain, both the device
being managed, and the application used to manage it, then you can do
as you wish; what ever makes the _most_ sense.
... and document it in your MIB (for the next guy)!
My opinion is, and my approach has always been,
if a MIB defines a variable, then the target _must_ implement that variable
and return an appropriate value 'in its current operational context'.
And that usually means: a) identifying all the possible contexts,
b) probably having another variable that communicates that 'current context'
and c) ensuring that 'appropriate values' are defined, returned and
documented
in my MIBs.
Then I (typically) write a companion management app, that knows how to
interpret and display all the various values, in context, in an intuitive
manner to the users.
If you are strictly/only using a MIB browser (or snmpget or snmpwalk),
then you can't provide a direct interpretation, all you can do is provide
'useful', 'decodable' data, that can be interpreted by a human, in context,
after they have read and understood your MIB.
So I might have a variable 'CurrentMode' that's defined as
'if in mode A', all variable have meaning, but
'in Mode B'... the values of 'x', 'y', and 'z' must be ignored. etc.
(But x, y, and z _are_ still implemented and return something 'legal'.
Its last known value, perhaps real, perhaps DEFVAL, perhaps zero or ''.
Its up to you, your context, and whatever makes the most sense.
------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
