Re: Opaque types

On Tue, May 24, 2011 at 9:55 AM, Leo Cacciari <[email protected]> wrote:
> Hi,
>  I'm writing a SNMP (sub)agent which would allow access to some
> application data. Data types handled by the application, and that should
> somehow be exposed to the SNMP world by the agent, includes the
> 'standard' SNMP types (e.g. 32 bits integers or [display]strings), some
> sub-types of those (e.g. 16 bits integers) and other types that are more
> difficult to map directly on SNMP types, although there is (obviously)
> no problem in mapping them to ASN.1 (that's the reason to have ASN.1,
> after all..).
>
> My first thought was to use OPAQUE type, adding necessary information
> using the DESCRIPTION clause. This idea seems to be supported by the RFC
> stating: "The Opaque type supports the capability to pass arbitrary
> ASN.1 syntax". However, the RFC also states that "The Opaque type is
> provided solely for backward-compatibility, and shall not be used for
> newly-defined object types.".
>
> My question to the collective wisdom is thus two fold:
>
> First, am I right in using the OPAQUE type? Or should I use another
> approach? Second, assuming the answer to the first question is "yes",
> how should I approach the problem of encoding/transmit/recover data
> using the OPAQUE data types?

Perhaps you should give us descriptions/examples of these 'other' types you have
before anyone passes on opinions.

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users