Re: [libsmi] Clarification req on Rfc:1905.......
Rfc:1905 (Protocol Operations of v2 SNMP) states that the following :
(7) If the variable binding's name specifies a variable which does not exist and could not ever be created ...... `noCreation'
(8) Otherwise, if the variable binding's name specifies a variable which does not exist but can not be created under the present circumstances (even though it could be created under other circumstances)... `inconsistentName
I cannot get the exact difference between 1 & 2.
[I've renumbered these as (7) and (8) to match RFC 1905: 4.2.5]
Consider the following scenario:
SET sysLocation.1="behind you"
sysLocation.1 does not exist, and cannot ever be created - it's a scalar object (not part of a table), so the only valid subindex is 0.
But sysLocation.0 *does* exist, so there is "some [variable] sharing the same OBJECT IDENTIFIER prefix [which] might under some circumstances be able to be created" (or at least modified, which is sufficient to pass 4.2.5 step (2))
Hence I'd expect this to return "noCreation".
Alternatively, consider a table, indexed by days of the week (perhaps an enumeration 1..7). Then you might get
SET wasIAtWork.sunday(1) = no(1) SET wasIAtWork.monday(2) = yes(2) : SET wasIAtWork.friday(6) = inBodyOnly(3) => wrongValue SET wasIAtWork.saturday(7) = no(1) SET wasIAtWork.8 = no(1) => noCreation
As far as "inconsistent name" is concerned, consider a similar table, indexed by days of the month, i.e. in the range 1..31. But not all these are necessarily valid for any given month (esp 31, and in February)
So this month I could run
SET thisMonthsSales.29 = 100000 SET thisMonthsSales.30 = 200000 SET thisMonthsSales.31 = 300000
quite happily. But trying the same thing during November - there is no November 31st, so the variable "thisMonthsSales.31" won't exist, and can't be created. (At least not given a good implementation!) But in different circumstances (e.g. December) the same variable *could* be created. Hence I'd expect this request to return "inconsistentName" during November.
A more realistic example might be:
SET printerOverallStatus.0 = down => OK SET printerQueue.queueStatus.1 = enabled => inconsistentName SET printerOverallStatus.0 = up => OK SET printerQueue.queueStatus.1 = enabled => OK
i.e. I can only enable a particular queue when the printer system as a whole is up. If the whole of the printer system is down, then I can't enable individual bits of it. So whether a particular request works will depend on "other circumstances".
Does that help any?
Dave
-- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
Hi,
Then what is the difference between 'inconsistentname' and 'inconsistentvalue'??? (i.e) difference bt. (8) and (10)in the Rfc.
Regards, Vivekanandan.V
-----Original Message----- From: Dave Shield [mailto:D.T.Shield@csc.liv.ac.uk] Sent: Friday, 7 December 2001 3:44 PM To: vivekav@future.futsoft.com Cc: libsmi@ibr.cs.tu-bs.de Subject: Re: [libsmi] Clarification req on Rfc:1905.......
Rfc:1905 (Protocol Operations of v2 SNMP) states that the following :
(7) If the variable binding's name specifies a variable which does not
exist
and could not ever be created ...... `noCreation'
(8) Otherwise, if the variable binding's name specifies a variable which
does
not exist but can not be created under the present circumstances (even though it could be created under other circumstances)... `inconsistentName
I cannot get the exact difference between 1 & 2.
[I've renumbered these as (7) and (8) to match RFC 1905: 4.2.5]
Consider the following scenario:
SET sysLocation.1="behind you"
sysLocation.1 does not exist, and cannot ever be created - it's a scalar object (not part of a table), so the only valid subindex is 0.
But sysLocation.0 *does* exist, so there is "some [variable] sharing the same OBJECT IDENTIFIER prefix [which] might under some circumstances be able to be created" (or at least modified, which is sufficient to pass 4.2.5 step (2))
Hence I'd expect this to return "noCreation".
Alternatively, consider a table, indexed by days of the week (perhaps an enumeration 1..7). Then you might get
SET wasIAtWork.sunday(1) = no(1) SET wasIAtWork.monday(2) = yes(2) : SET wasIAtWork.friday(6) = inBodyOnly(3) => wrongValue SET wasIAtWork.saturday(7) = no(1) SET wasIAtWork.8 = no(1) => noCreation
As far as "inconsistent name" is concerned, consider a similar table, indexed by days of the month, i.e. in the range 1..31. But not all these are necessarily valid for any given month (esp 31, and in February)
So this month I could run
SET thisMonthsSales.29 = 100000 SET thisMonthsSales.30 = 200000 SET thisMonthsSales.31 = 300000
quite happily. But trying the same thing during November - there is no November 31st, so the variable "thisMonthsSales.31" won't exist, and can't be created. (At least not given a good implementation!) But in different circumstances (e.g. December) the same variable *could* be created. Hence I'd expect this request to return "inconsistentName" during November.
A more realistic example might be:
SET printerOverallStatus.0 = down => OK SET printerQueue.queueStatus.1 = enabled => inconsistentName SET printerOverallStatus.0 = up => OK SET printerQueue.queueStatus.1 = enabled => OK
i.e. I can only enable a particular queue when the printer system as a whole is up. If the whole of the printer system is down, then I can't enable individual bits of it. So whether a particular request works will depend on "other circumstances".
Does that help any?
Dave
-- !! This message is brought to you via the `libsmi' mailing list. !! Please do not reply to this message to unsubscribe. To subscribe or !! unsubscribe, send a mail message to libsmi-request@ibr.cs.tu-bs.de. !! See http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information.
participants (2)
-
Dave Shield -
Vivekanandan V