[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
> > 
>