[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
   it does?

   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
      the type?)

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
   correspond to?

      - 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)
   won't work.

   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.


Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group