[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.

We are talking about new code here. The agent should not 'blindly
apply element addresses' - OIDs. 

> 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.

I think this should be an instruction ot the implementor (those that
choose to autopopulate the element table - which I think is a good
thing). I could see a script writer doing this. I have more envisioned
it to be a part of the rest of the management sub system on the device.
That is they should know what to register - after all the info is pretty
easy when doing the agent code.

> 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.
> Done.
> > 
> > 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.

I agree 100% with the StorageType object dictates this. My point in
raising the issue is that may not be obvious to many readers.

> Steve


Jon Saperia		     saperia@jdscons.com
			     Phone: 617-744-1079
			     Fax:   617-249-0874