RE: updated TimeFilter text

Hi Andy,



> -----Original Message-----
> From: Andy Bierman [mailto:[email protected]] 
> Sent: Thursday, February 10, 2005 11:59 AM
> To: [email protected]
> Cc: 'Wijnen, Bert (Bert)'; [email protected]; 'David Kessens
(E-mail)'
> Subject: RE: [RMONMIB] updated TimeFilter text
> 
> >How does an NMS know that a new row has been created, and the NMS
> >should now set maxReps=3 rather than 2? [...]
> 
> Who says there is any functional requirement to optimize TimeFilter
> with GetBulk for row discovery?  The row will get discovered,
> but in a subsequent poll.  

But it won't get discovered in a subsequent poll if the created row
doesn't change, if the subsequent poll is filtered using a TimeFilter
of <changed since the last poll>, will it? 

Sequence:
A. Poll time=0
B. Row created
C. Poll time=A (but row happens to get filtered by maxReps)
D. Poll time=C (row creation at B is now filtered out by TimeFilter)
	"if (last_modified_timestamp < index_value_in_pdu) return
FALSE;"

Temporary loss of information due to unreported rows is a general
problem with maxReps, to be sure. However, the filtering provided by
maxReps and the filtering provided by TimeFilter interact to prevent
the created row from being discovered in subsequent polls (unless
values in the row change between subsequent polls). If subsequent
polling was not filtered by TimeFilter, then the row-creation-event
might be detected in a subsequent poll.

I think implementors should be warned of this interaction of filters.
The examples are inadvertently misleading in that they use an exactly
accurate maxReps based on the author's knowledge of the examples, but
this accuracy is not available to NMSs when generating getBulk
commands with TimeFilters.

I suggest that the simplest approach would be modify the maxReps in
the examples, add ellipses to the examples where the extra reps would
be, and preface the NMS-side examples with a note to the effect that
maxReps should be set to a value that is likely to exceed the number
of row changes reasonably expected to occur between polls. Rows
filtered out by maxReps are not