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

Re: snmpconf Policy MIB: elements




Steve,

Thanks for the detailed reply.  I'll try to give you some
editorial suggestions later, but the key idea here is
that for a multi-table element, everything is done by
means of the "first" table.  I think I started off down
the path of focusing on the "second" tables because I
was unconsciously equating Element Types with Policy
Roles (in the PCIM sense).  These Policy Roles are
usually at the level of Dot3Interface or
FrameRelayInterface, rather than at the higher level of
Interface.  (It's certainly possible to imagine policies
that are supposed to apply to all interfaces -- this
just isn't the typical case.)  So I guess part of the
message needs to be that an Element Type *isn't* a
Policy Role.  It's more like just a vehicle for getting
to instance identification information to go into your
.$0's.

One question does come to mind: is there always going
to be a "first" table to serve as the point of contact
for an element type?  I tried to build a counterexample,
where there were two tables that both shared an INDEX
consisting of one object from the first table and one
object from the second table.  SMICng grumbled about
this (W: f(tester.mib), (52,15) Row "firstEntry" does
not have a consistent indexing scheme - index items from
containing row must be last in the INDEX clause), but
it didn't flag it as an error.  So I'm not sure exactly
how to express the idea that an element type is
identified by / associated with its "first" table.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com



Steve Waldbusser <waldbusser@nextbeacon.com>@snmp.com on 03/08/2001
09:22:39 PM

Please respond to snmpconf@snmp.com

Sent by:  owner-snmpconf@snmp.com


To:   snmpconf@snmp.com
cc:
Subject:  Re: snmpconf Policy MIB: elements




Hi Bob,

  You bring up some good questions. Let me try to clarify here and
figure out how to make the document more clear.


Robert Moore wrote:
>
> 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...,"

Exactly. And it's not bad terminology, it's wrong terminology - it was a
typo.

> where these entries
>    correspond to element *types*, not to elements.

Yes.

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

Yes again.

The talk about elements occurs for the following reason.
   The 3 paragraphs starting with "Note that agents..." are dealing
   with elementType entries that come installed "out of the box". The
   agent might want to install some entries for convenience sake
   (saving some set requests), but there are a couple of reasons that
   are much more compelling:

   1) The agent might have specialized code that scans internal data
   structures for certain element types rather than doing a getNext
   walk; or,
   2) The agent might be able to register for a card-inserted
   interrupt or signal and learn of elements without polling.

   These reasons are much more compelling because they require
   specialized code per element type - stuff that ain't gonna happen
   automatically by decoding some new OID value. In other words, while
   I can teach an agent to walk a new table by downloading a new OID,
   I can't cause it to grow new code for these specialized
   techniques. So since the code is already hardwired, and thus the
   support for the elementType, the agent can hardwire the
   elementTypeRegEntry and make everyone's life easier.

This wasn't intended to blur things by talking about elements but to
describe the pre-installed behavior of elementTypeRegEntries.

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

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.

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

Maybe it could be, I was just trying to be careful. It was hard to
declare at the moment I was writing that text that: "the first
accessible column in the table will *always* be appropriate". On the
other hand, I really can't think of any reason why not.

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

Assume this baseline "normal" code (a filter):

    if (insubtree(elementName(), "ifEntry")
        && getvar("ifOperStatus.$0") == 1)
        return 1; // Match
    else
       return 0;

What I'm trying to say is the following code is also valid:

    if (insubtree(elementName(), "ifEntry")
        && getvar("ifOperStatus.$0") == 1
        && getvar("dot3StatsDuplexStatus.$0") == 2)
        return 1; // Match
    else
       return 0;

Note that the element type is ifEntry, and we are using the address of
ifEntry elements ($0), but we are using dot3StatsDuplexStatus as one of
the "attributes" of this element. We don't need to create an elementType
for dot3Entries.

Let me add that the agent doesn't need to know that this is happening.
It doesn't need to be set up to know that $0 will also index
dot3Entries. It just blindly replaces $0 with the current value of
ifIndex for elements of type interface. Only the script writer needs to
know which tables share the same index and can thus be modeled this way.

Maybe part of the problem is that the topic sounds complicated
("abstract superclass" and so on) and yet the mechanism is so blindingly
simple ("blindly replacing $0").

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

I don't see why this is so.

In fact, it is very important that the ifEntry type be registered
because it is the one that is guaranteed to discover all interface
instances (registering dot3Entry would only find a subset).

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

Ditto.

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

You really only want to register ifEntry. If you *did* register both, I
suppose the answer would be "two elements, one of each type". More
concretely speaking, an entry in the dot3StatsTable would have a policy
executed twice on it, once as an interface and once as a dot3Interface.

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

I hope my answers above make this more clear. Just register ifEntry and
all will be fine. There will be no duplicates. You will be able to use
$0 as the index to attributes that are in the ifTable, the
dot3StatsTable, the Dsx1ConfigTable, or a private locIfTable.

If you were to register the "second" table (there's no law against it),
there would be no duplicate detection (the agent doesn't really know
enough to do such duplicate detection anyway).

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

Again, don't register the "secondary" tables. But if you did, the roles
registered to the base element type will not be registered to the
secondary element type. So if you wanted to make this work (no reason
you would) you would have to register the same roleStrings to
dot3StatsIndex.7 as you did to ifIndex.7, and so on.

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


You're off the hook on both counts. It hasn't been discussed and even if
it had, you're right: it needs to be readable by people who will never
participate in our discussions.

Unfortunately in this message I haven't proposed any wording changes to
help out. Can I propose that once I get you on the right track, that you
might be able to help by pointing out what text set you on the wrong
path or with suggestions on a more clear way to describe this?


Thanks,
Steve