On 21/01/2008, Manfred Wassmann wrote:
> I actually have at least two instances of myVersion
> but they have to have different access clauses, so I guess I can't put
> them into one table.

Not so - remember that the access clause is actually MAX-ACCESS.
So you could have a MAX-ACCESS of read-write (or read-create) for
the column object, and explain any further restrictions in the relevant
description field.

It's a bit difficult to give more precise advise without knowing more
about what exactly you are trying to do.

> Yet I wonder why I can't combine them into a third entity like
> it is done in the UCD-SNMP-MIB:
> logMatchEntry OBJECT-TYPE
> SYNTAX LogMatchEntry
> [...]
> LogMatchEntry ::=
> logMatchIndex
> Integer32,
> [...]

As Mike has said, this is part of a table.
SNMP MIB structures can be either standalone scalar objects,
or tables - a set of nested definition of the form

xxxTable ... SEQUENCE OF XxxEntry ...
xxxEntry ... XxxEntry ...
XxxEntry ::= SEQUENCE { ..... }
(followed by the column objects).

These are the *only* two data structures supported in SNMP.
(Being part of the "Simple" aspect of things).

There was talk a few years ago about re-working the SMI specs
to support more complex structures, but that came to nothing.

In practise, scalar objects and tables (together with appropriate
descriptions and Textual Conventions) are sufficient to handle
most requirements. Though this does rely on application/agent
designers looking at the defined semantics of a given MIB - not
just the basic syntax.


This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Net-snmp-users mailing list
Please see the following page to unsubscribe or change other options: