[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
snmpconf Policy MIB: elements
Clearly the concept of an element is at the very
center of the Policy Management MIB. But I'm having
a hard time getting my hands around this concept
I can break my questions down into three broad groups:
1. The Element Type Registration table
In the discussion in Section 6.1, much of which
is repeated back in the MIB module, I'm confused
about the relationship between elements, element
types, and entries in the table. I think part of
the problem is just bad terminology; for example,
I think that "Note that agents may automatically
configure elements in this table..." is really
saying "...agents may automatically configure
*entries* in this table...," where these entries
correspond to element *types*, not to elements.
The next few sentences blur the picture, however,
by bringing in discover of *elements* (like the
asynchronous notification of new elements like
"card inserted" -- here this does seem to be
talking about an element rather than an element
type). Elements exist in their own tables, not
in this table. So it's a bit confusing for them
to come into the discussion at this point.
Here's what I make of this table. The first
question is, am I right? Second, can the document
say whatever is right here a lot more clearly than
a. The entries in the table correspond to element
types. They can be created either via a
management flow or by the agent.
b. For each element type, the agent has a means of
discovering elements of that type. These means
may be different for different types.
c. For some element types, the agent will create
a new element type entry in this table when it
discovers the first element [instance] of that
type. Discovery of subsequent elements of the
type will have no effect on the table. (Or do
these entries corresponding to "frequently used
element types" exist all the time, even before
the agent has discovered the first element of
2. Elements in general
The first paragraph in Section 6.1 makes a
distinction between what I'll term "single-table
elements" and "multi-table elements". Most of my
element questions pertain to multi-table elements;
they're below, under number 3. I do have one
question even for single-table elements, though.
The question is, why is *any* columnar OID allowed
to identify an element type, leading to the
clumsy-sounding rule that to detect duplicate
element types, the last arcs of their OIDs must
be ignored? Is there any reason the OID for a
(single-table) element type can't be defined to be
the first accessible column in the table, similar
to how the RowPointer TC is defined?
3. Multi-table elements
Here's where I really get lost. Taking the
example from Section 6.1, an entry in the ifTable
and the entry in the dot3Stats table with the
same value for ifIndex together make up one
element. For cases like this, where there's a
second table that reuses ifIndex, it seems like
the element type should correspond to the second
table -- say, "dot3Interface". But in other cases
there is no second table: all the information that
exists for an interface is in the ifTable. In
these cases it seems like the element type will
have to be just "interface".
The problem here seems to be that in some cases,
"interface" and the ifTable function like an
abstract superclass, while in other cases they
function like a concrete class. I'm not sure how
to represent this in the Element Type Registration
table. If there's an entry there for "interface"
(needed for the interface types that don't have a
"second" table), and also one for "dot3Interface",
then what does an instantiated dot3Interface
- an element of the type "interface"?
- an element of the type "dot3Interface"?
- an element of both types?
- two elements, one of each type?
It's also not clear what happens when there are
multiple "second" tables, as there are in a number
of standard MIBs (and even more so when you bring
in vendor extensions to standard MIBs). Does an
element correspond to the union of all the table
entries in the agent that share the same index
values? If so, what is its element type? Without
a clear answer to this question, the algorithm for
detecting duplicate element types (strip off the
last arc of the OIDs, and compare what's left)
A third question relates to the various RowPointer
objects in the MIB that point to multi-table
elements. As RowPointers, these objects must
point to the first accessible object in a
conceptual row. But conceptual row in which table?
The rows that together make up a multi-table
element will share index values, but they don't
share their tabular/columnar OIDs. So these
RowPointers will be different, depending on which
of an element's tables they point to.
By the way, I apologize a little if any of this has
been discussed on the list over the past couple of
months, while I've been buried in PCIM Extensions.
But I don't apologize very much: by the time we're
done, the information must be in a form where it's
communicated by the document alone, without reference
to any outside knowledge. So think of me as an early
test case of a reader coming into this material cold.
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group