RE: Help/guidance on L2TPv3 MIB draft

["Natale, Robert C (Bob)" <bnatale@lucent.com>]

Hi Margaret,

Comments inline:

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

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.

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

Understood...good luck.

Cheers,

BobN