RE: [RMONMIB] proposal to fix TimeFilter problem

["Romascanu, Dan (Dan)" <dromasca@avaya.com>]

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
>