[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AggregateMIB proposal; Was Re: IETF 53 Draft EOS WG Draft Meeting Minutes
Continuing the discussion on the Aggregate-MIB from where we left
it off at the last IETF :
> Q: Other MIBs such as disman, rmon, esp. expression have similar
> A: This MIB has a narrower focus.
> Q: What about looking at "entire" table, which raises questions of how
> to deal with row creation and deletion?
> A: This proposal doesn't address issues of monitoring an entire table,
> since it must be explicitly configured with all the instances to be
> Q: What happens when specific instance being monitored disappears?
> A: Need to look at this issue.
There will a No Such Object or Instance.
> Observation: Looks like the user history table in RMON, except this
> packs values into since variable binding. Sampling begins when MIB
> configured, so nothing special about the get/response sequence. We may want
> to look at a more generic solution to this problem.
> Resolution: No action to accept this work at this point in time. Further
> discussion to be taken to the mailing list.
The relationship with some of the existing MIBs (this came up during
RMON History Group:
It is possible to program the RMON history group so that the
time development of an MO is recorded. This solves the sampling issue.
1. The fetching of the history follows the traditional practice.
To collect the history of the MO, the manager will need to be
perform "get"s on each instance of MO.
There is no savings on bandwidth, no compression.
2. The minimum relolution available is 1 second.
This probably comes closest to the approach of AggregateMIB.
New MOs may be defined as functions/expressions of other MOs.
1. an aggregation operator is not defined (the concatenation
operator is available only for MOs of type octet-string
or Object Identifier)
2. Expressions cannot be (easily) formed to represent the
time development of an MO
It is interesting to note that if the expression MIB is on a
mid-level manager it would be profitable to define an Aggregate
MO to fetch all the MO instances pertaining to an expression
and thence compute the value of the expression.
In fact I like seeing the closeness of the ExpressionMIB and the
AggregateMIB - AggregateMIB seems to be a natural evolution of the
Any comments ?
Glenn M Keeni
PS. The draft has expired. I am working on getting an updated version
uploaded before the end of the next week.