RE: Help/guidance on L2TPv3 MIB draft

[Randy Presuhn <rpresuhn@dorothy.bmc.com>]

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
 randy_presuhn@bmc.com  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------