[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf Policy MIB: elements

Jon Saperia wrote:
> Bob/Steve,
> The conversation about Element discovery is a good one. I have a couple
> of points that are related:
> > A and B are correct, but C isn't.
> >
> > The agent won't do discovery of elements that aren't listed in the
> > elementTypeRegTable. In most cases the manager writes an entry into the
> > table, in effect saying "I want to have some policies that act on
> > elements of the following type. Please discover and manage execution for
> > elements of this new type". So if ifEntry is not represented in the
> > table, policies will not be run on interfaces. Further, even if there
> > are no circuits at the moment, there can be a frCircuit entry in the
> > table that causes the agent to continuously check for new circuits.
> I agree with Steve in terms of the importance of allow for 'specialized'
> code. One rewording I would like to help avoid the problem Steve pointed
> out. From Section 5.2 Element Discovery on page 9:
> Change:
> > For example, the ifTable and the dot3Stats table both contain
> > attributes of interfaces and share the same index (ifIndex),
> > therefore they can be modeled in this model as one element
> > type.
> to:
> For example, the ifTable and the dot3Stats table both contain
> attributes of interfaces and share the same index (ifIndex),
> therefore they should be modeled in this model as one element
> type.
> I think 'should' more clearly conveys the intent and level of what an
> elment type is intended to be.

I'm a bit leery of this. The agent doesn't participate in this (it's
just blindly applying element addresses). The manager who sets up the
elementTypeRegTable only indirectly participates in this (by choosing
not to register the dot3StatsTable - but in fact this is really directed
by the script writer). The entity that does this is the human script
writer who chooses to borrow $0 from interface elements and apply it to
any other table indexed by ifIndex, conceptually extending the interface
element to contain a whole new list of attributes.

In other words, this isn't an instruction to the implementor, this is an
instruction to the user that is unenforceable by the agent or manager.
I'm leery of dictating to the script writer how they should design their
script, particularly when it would still work the other way. It's kindof
like if the C spec said that programmers should not use goto.

The text was originally supposed to point out a modelling opportunity
that script writers have - a modeling practice that I think will become
an idiom.
> Also from page 9:
> > The Element Type Registration table is used for the manager to
> > learn what element types are being managed by the system and
> > to register new types if necessary. An element type is
> > registered by providing the OID of an SNMP object (i.e.,
> > without the instance). Each SNMP instance that exists under
> > that object is a distinct element. The address of the element
> > is the index part of the discovered OID. This address will be
> > supplied to policy filters and actions so that this code can
> > inspect and configure the element.
> Change 'used for the manager' to used by the manager.


> We probably also want a word or two in the table definition that says
> talks about interactions where a Manager attempts to delete or modify a
> row that has been 'discovered' by an agent. I would bet the behavior
> that one would want is that the manager overrides native behavior for
> the length of time of pmElementTypeRegStorageType.

The semantics of the StorageType object cover this - and the answer is
that the behavior depends on the value of storageType. Mostly I think
that readOnly or permanent will be used.