[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