[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RMONMIB] proposal to fix TimeFilter problem
At 05:42 PM 2/4/2003 +0100, Wijnen, Bert (Bert) wrote:
>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?
No. I was talking about reving this group. (Clone it as
probeConfigurationGroupRev1, add the new object, deprecate the old group).
>Thanks,
>Bert
Andy
>> -----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
>> >
>>
>_______________________________________________
>RMONMIB mailing list
>RMONMIB@ietf.org
>https://www1.ietf.org/mailman/listinfo/rmonmib