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

Reply via email to