[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RMONMIB] proposal to fix TimeFilter problem
In fact, I believe that it is not allowed to add a new
object to an existing OBJECT-GROUP. As per RFC2580:
7.1. Conformance Groups
It may be desirable to revise the definition of a conformance group
(an OBJECT-GROUP or a NOTIFICATION-GROUP) after experience is gained
with it. However, conformance groups can be referenced by compliance
and/or capabilities definitions. Therefore, a change to a
conformance group is not allowed if it has the potential to cause a
reference to the group's original definition to be different from a
reference to the updated definition. Such changes can only be
accommodated by defining a new conformance group with a new
descriptor and a new OBJECT IDENTIFIER value.
But maybe you were not talking about the probeConfigurationGroup
OBJECT-GROUP, were you?
Thanks,
Bert
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> Sent: dinsdag 4 februari 2003 16:55
> To: Andy Bierman; rmonmib@ietf.org
> Cc: mibs@ops.ietf.org
> Subject: RE: [RMONMIB] proposal to fix TimeFilter problem
>
>
> I would prefer to add it as a new group. The reason is that
> other MIB modules than RMON-2 may be using the TimeFilter TC.
> I assume their compliance clauses would include in the future
> this object.
>
> Dan
>
>
>
>
> > -----Original Message-----
> > From: Andy Bierman [mailto:abierman@cisco.com]
> > Sent: Tuesday, February 04, 2003 12:06 AM
> > To: rmonmib@ietf.org
> > Subject: [RMONMIB] proposal to fix TimeFilter problem
> >
> >
> > Hi,
> >
> > The RMONMIB WG decided at the last IETF that the timeFilter
> > get-next-forever
> > problem should be fixed. I am proposing the following MIB
> > object, which
> > should be added to the RMON2-MIB module. It could either
> be added to
> > the probeConfig group or added to a new group. The
> MIN-ACCESS of this
> > object would be read-only.
> >
> >
> > timeFilterMode OBJECT-TYPE
> > SYNTAX INTEGER {
> > stopAfterOne(1),
> > stopAfterAll(2)
> > }
> > MAX-ACCESS read-write
> > STATUS current
> > DESCRIPTION
> > "This object controls the way the SNMP agent implements the
> > getnext operation for tables with a TimeFilter index, such
> > as those found in the RMON2-MIB module.
> >
> > If this object has the value `stopAfterOne(1)', then
> > a GetNext
> > or GetBulk operation will provide one pass through a
> > given table,
> > i.e., the agent will continue to the next object or table,
> > instead of incrementing a TimeMark INDEX value, even if
> > there exists higher TimeMark values which are valid for
> > the same conceptual row.
> >
> > This mode is not strictly compliant with the
> > TimeFilter textual
> > convention definition, because potentially many
> > conceptual rows
> > will be skipped instead of returned in a GetNext or GetBulk
> > operation. Such rows are identical to each other,
> except for
> > the returned TimeMark INDEX value. This mode is
> intended only
> > for testing purposes, however it may also be
> useful if an NMS
> > wishes to utilize the GetBulk PDU. This mode will
> prevent the
> > GetBulk responses from containing duplicate rows due to the
> > TimeFilter mechanism.
> >
> > If this object has the value `stopAfterAll(2)', then
> > a getNext
> > or getBulk MIB walk will repeat through the same MIB
> > table until
> > the TimeMark for the most-recently changed entry
> is reached.
> > Note that as long as traffic occurs on the monitored
> > interface,
> > it is possible a highest value of the TimeFilter INDEX may
> > never be reached. This mode is strictly compliant with the
> > TimeFilter textual convention definition. Note
> that GetBulk
> > PDU responses in this mode will likely contain
> > multiple copies
> > of the same MIB instances, differing only in the
> > TimeMark INDEX
> > value.
> >
> > As an example, consider row 'fooEntry' which was
> last updated
> > at 'time 1000'. An NMS may use any TimeMark INDEX
> > value in the
> > range '0' to '1000', and the current (i.e., time of
> > get request)
> > counter values for the 'fooEntry' will be returned
> by agent.
> > In the 'stopAfterOne' mode, the agent will not increment
> > the fooEntry TimeMark index under any conditions. In the
> > 'stopAfterAll' mode, the agent will increment any fooEntry
> > TimeMark INDEX value in the range '0' to '999', up until
> > the TimeMark value of '1000' is reached."
> > DEFVAL { stopAfterAll }
> > ::= { probeConfig 15 }
> >
> > _______________________________________________
> > RMONMIB mailing list
> > RMONMIB@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rmonmib
> >
>