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?
Thank you in advance.
Kind regards,
PCFE
----- Original Message -----
From: "Fulko Hew" <fulko....@gmail.com>
To: "PCFE" <p...@newtec.eu>
Cc: net-snmp-users@lists.sourceforge.net
Sent: Monday, February 18, 2013 2:59:06 PM
Subject: Re: Applicability in SNMP scalar objects
On Mon, Feb 18, 2013 at 6:05 AM, PCFE < p...@newtec.eu > wrote:
What is the correct way to show applicability
of SNMP Scalar Objects when doing an SNMP-GET request?
For example, imagine that we have a monitoring
parameter that is only valid under
certain system configuration:
- Should we return a noSuchObject error, and act like
the object is temporarily not implemented?
- Should we return a noSuchInstance error?
- Should we provide an 'not-applicable value',
that is returned in this cases?
Certainly an option, but only if you have an enumeration where you can add
that value. Or be able to define other 'illegal values' that could be
interpreted
to represent 'not-applicable'.
- Should we return the DEFVAL?
NO, because its probably not the right value at the time.
- Any other option?
Your best bet is to add a not-applicable value to your variables
and document that behavior in your MIB. I have some variables
that have a 'not-applicable' enumeration, and have other
numeric/configuration _values_ where fortunately only positive numbers
are useful configurable values and that let me define (-1) as a
value that tells remote agents that this option is 'disabled'.
It all depends on the values/variables that you have.
And when it comes to some OCTET STRINGS, I have on occasion
defined the 'empty string' as a not-applicable value. Again it depends
on the definition of you variables.
Is there a clear explanation for this in the RFC's ?
There are conventions for creating/destroying rows in a table,
but I don't recall anything surrounding variables themselves.
Its an application/device specific requirement.
Newtec's New Complete Modem Portfolio... Discover more @
http://newproducts.newtec.eu
*** e-mail confidentiality footer *** This message and any attachments thereto
are confidential. They may also be privileged or otherwise protected by work
product immunity or other legal rules. If you have received it by mistake,
please let us know by e-mail reply and delete it from your system; you may not
copy this message or disclose its contents to anyone. E-mail transmission
cannot be guaranteed to be secure or error free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain
viruses. The sender therefore is in no way liable for any errors or omissions
in the content of this message, which may arise as a result of e-mail
transmission. If verification is required, please request a hard copy.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
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
