Hi Dave,
Thanks for the clarification,
i have gone through the RFC RFC 3416, section 2.5, para 2 as you refereed.
Now i have got one more question, the rule of encoding the bits is
applicable for both SNMP manager(during SNMP SET) and SNMP client(during
SNMPGET/SNMPWALK operation).
Does SNMP Client has real reverse the bits when queried through SNMPGET,
irrespective of the bit length(either 8 bits or 64 bits).
Regards,
Venkatgiri
On 06/28/2011 03:52 PM, Dave Shield wrote:
> On 28 June 2011 11:04, venkatgiri<venkatgir...@globaledgesoft.com> wrote:
>> As per RFC 1212 section 5.1.1. Mapping to the SYNTAX clause
>>
>> (3) An object with BIT STRING syntax containing no more than
>> 32 bits becomes an INTEGER defined as a sum; otherwise if
>> more than 32 bits are present, the object becomes an
>> OCTET STRING, with the bits numbered from left-to-right,
>> in which the least significant bits of the last octet may
>> be "reserved for future use".
> Please note that this is talking about mapping the OSI type "BIT STRING"
> into an SNMP equivalent. It does *NOT* refer to the SNMP "BITS" pseudo-type
>
> See RFC 2578, section 7.1.4 for a discussion of the BITS construct
>
>
>> QUE 1. should we implement the object as OCTET string syntax or BIT STRING
>> syntax (if it is of 64bits).
> Forget about BIT STRING - it's not relevant here.
> Use BITS (which is essentially an octet string)
>
>
>> QUE 2. example:
>> lets take one object xyz
>> whose syntax is BITS {
>> a(0),
>> b(1),
>> c(2),
>> d(3)
>> .....
>> A(60)
>> B(61)
>> --
>> F(63)
>> }
> As an aside those last few names are not valid.
> See the final paragraph of section 7.1.4
>
>
>> Here if the bits from 0 to 19 are set means, how we should set
>> i) either from left to right [left = 0th bit(LSB), right(63rd bit (MSB))]
>> ii) or from right to left [right = 0th bit(LSB), left(63rd bit (MSB))]
> The first eight bits are mapped into the first octet of the string (MSB
> first),
> the next eight bits are mapped into the second octet, and the
> remaining three bits are mapped into the top three bits of the
> third octet.
>
> See RFC 1906/3417, section 8, item (3)
> and/or RFC 3416, section 2.5, para 2 for details.
>
> Dave
>
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
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
