Re: Need Info abt the SNMP SET.

[venkatgiri <ven...@gl...>]

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<ven...@gl...>  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
>