[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf Policy MIB: elements
Jon Saperia wrote:
> > > 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.
(I don't understand the 1st sentence).
Maybe I shouldn't use provocative words like "blindly apply", but it's
accurate. If my script tells the agent to append the index of an ifEntry
to an object in the dot3StatsTable, the agent should just do it
(blindly). It's just appending another subid to an OID. It doesn't know
about table structure so it couldn't complain even if it wanted to.
> > 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.
Bob's 1st question was the one the refers to autopopulation. I think
we're discussing his 3rd question which deals with modeling a single
element type even though the information is in separate tables by virtue
of the fact that the indexes are shared. This is a decision for the
PolicyScript author to make.
> > 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.
> > > 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.
OK. How about the following text:
"Note that the disposition of agent-installed entries is described by
the pmPolicyStorageType object."