Subject: Re: Help/guidance on L2TPv3 MIB draft

From: Steve Moulton <[email-masked]>
Date: Mon, 30 Sep 2002 09:27:15 -0400

On Sunday, September 29 2002, "Natale, Robert C (Bob)" <[email-masked]> wro
te:

> At 8/19/2002:08:26 PM, Jed Lau <[email-masked]> wrote:
> 
> Hi Jed,
> 
> Please review this MIB for compatibility with the
> IETF standard SNMP agent extensibility protocol,
> AgentX (RFC2741...and RFC2742 can also give you
> some additional insight into AgentX operations).
> 
> The fundamental issue is that scalar objects are
> potentially problematic for AgentX. They should be
> avoided by putting them into a table indexed by
> some form of "AgentEntityID" object (an exercise
> left to the implementer for now :-().
> 
> Note that the issue of AgentX compatibility for
> MIB writers will be addressed in a forthcoming
> Internet Draft that I will submit...perhaps with
> an extended applicability statement for AgentX
> (Sections 4.2, 4.3, and 4.4 of RFC2741 do a good
> job of the basics already)...for consideration by
> the relevant IETF WGs. My hope is that consideration
> of this Draft will lead to adding a statement or two
> to the standard "SNMP Framework" boilerplate to
> document these requirements for MIB writers.
> 
> Guidance from Bert re where to discuss this
> issue -- AgentX compatibility guidelines for
> SNMP MIBs -- will be appreciated. (The AgentX
> e-mail list is still operative, but the WG is
> closed pending further work when its time to
> move to Full Standard status.)

Perhaps AgentX could receive some attention to fix
this shortcoming, rather than force MIB writers to
use artificial constraints that are not a part
of, and rather unnatural to, SNMP.  This kind of
artificial constraint (Andy might say CLR) does 
little other than impede SNMP (and SNMPv3) acceptance.

        - Steve
---
Steve Moulton        SNMP Research, Inc            voice: +1 865 573 1434
Sr Software Engineer 3001 Kimberlin Heights Rd.    fax: +1 865 573 9197
[email-masked]     Knoxville, TN 37920-9716 USA  http://www.snmp.com

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 30 Sep 2002 10:48:10 -0400

>
>I guess you two are not well communcating. My understanding is that
>Bob talks about objects such as ifNumber which are problematic when
>the counted ifEntry rows exist in different sub-agents. I do not think
>Bob is talking about scalars in general, which is what Andy seem to
>have in mind.

I never understood the value of the "fooNumber" variables to begin
with...

They are complex to maintain for a large, dynamic table (like a
routing table).

They don't reflect the number of entries that are actually
visible to the manager, so a manager can't expect to see that
number of entries in the table.

And, for a large, dynamic table, the number of entries is likely to
change in the time it takes to do enough get-nexts and/or get-bulks
to download it.

But, assuming that you believe that they have any use at all...

Why would it be more useful to present them as a table?  And,
how would you index such a table?

Not just idle speculation -- I'm working on a MIB right now that (for
historical reasons) will probably continue to have one of these
irritating little buggers...

Margaret

---

From: "Natale, Robert C (Bob)" <[email-masked]>
Date: Tue, 1 Oct 2002 14:03:56 -0400

> -----Original Message-----
> From: Steve Moulton [mailto:[email-masked]]
> 

To repeat:

It has nothing to do with any "shortcoming" in AgentX --
the IETF standard extensible agent protocol supports
singly instanced MIBs just fine (RFC2741, 4.2.1, again).

It is however an "artificial constraint", of singly
instantiable MIBs.  It is that defect in many existing
MIBs (not its correction) that has, in part, retarded
SNMP deployment.

From an information engineering perspective, all MIBs
should be designed for multiple instantiability.  That
quality is (and always has been) readily available (with
trivially incremental design effort and runtime cost) in
the existing SMI -- and it would virtually have to be,
since multiple instantiability is a fundamental attribute
of shared data models.  Single instance runtime configs
are merely a natural subset.

Cheers,

BobN

---

From: "Natale, Robert C (Bob)" <[email-masked]>
Date: Tue, 1 Oct 2002 15:16:14 -0400

Hi Margaret,

> change in the time it takes to do enough get-nexts and/or get-bulks

Correct on all counts, IMHO.  However, it must use such scalars
in new MIBs, AgentX can support them in various ways:  E.g.,
perhaps you the MIB will never need to run in a multiply instanced
configuration or perhaps the "registration priority" feature of
AgentX can identify one sub-agent instance that will track such
non-static scalar value.  (Note that the latter approach would
most likely require sub-agent to sub-agent communications that are
outside the scope of AgentX.)

> But, assuming that you believe that they have any use at all...

If you must use such non-static scalars in new MIBs, AgentX can
support them in various ways:  E.g., perhaps you the MIB will never
need to run in a multiply instanced configuration (no brainer case)
or perhaps the "registration priority" feature of AgentX can identify
the one sub-agent instance that will track such non-static scalar value.
(Note that the latter approach would most likely require sub-agent to
sub-agent communications, for value aggregation, that are outside the
scope of AgentX.)

[Note that thinking about the different nature, in general, of
static scalar objects and those that report dynamic values can be
very illuminating:  Static scalars will almost certainly show sub-
agent-specificity by nature; dynamic scalars will often prove to
be redundant wrt information available via tables in the MIB.]
 
> Why would it be more useful to present them as a table?

So that multiple sub-agents could maintain their respective values
independently.

> And, how would you index such a table?

The agentx-IndexAllocate-PDU could be used to manage index
assignments.

An "agentEntityID" object of some kind...a simple INTEGER index
would probably suffice...a TC to be used by all might be appropriate
...several common forms of MIB-specific approaches, while least
desirable, would not necessarily be outlandish...I'm not trying to
design or recommend a specific approach here.

> irritating little buggers...

Understood...good luck.

Cheers,

BobN

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 1 Oct 2002 17:29:55 -0700 (PDT)

Hi -

At least three different issues in this thread:

The "problematic" scalars are symptomatic of assumptions
about implementation architecture that, if they're going to
be made at all, should be made explicitly.  Specifically,
these objects like ifNumber are straighforward in systems that
have centralized resource allocation for the type of resource
in question, and are a real pain in systems which would not
otherwise need to devote a task to tracking the allocation /
deallocation of a particular resource type.

In the spirit of the eos and sming discussions, I think we'd do
well to remember that snmpv3 and agentx have contexts because
the working groups recognized the reality of the fundamental
limitations of the naming architecture.  If the designer of
a MIB didn't get everything into the INDEX clause that would
be necessary for every possible system configuration, one is
forced to resort to contexts to do the naming.  Architectures
that employ relative distinguished names (e.g., X.500) don't
have this problem, but pay for it with a more complex
discovery process.

Having common, protocol-independent instrumentation across
all target platform architectures might be the "right"
way to go, but protocols like today's SNMP put such strong
constraints on the data model that the benefits of doing so
would be severely compromised.  And then there's that little
problem of actually establishing such a standard API with an
interoperable protocol to go with it.  It'd be nice, but I'm
not going to hold my breath waiting for it.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  SJC-1.3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------