RE: updated TimeFilter text

Hi,

The text which discussed the "padding" effect in a GetBulk has been
removed from the previous revision. What was the rationale for
removing that text completely?

The example for Time nms-2500 has maxreps=2, but returns three
repetitions, doesn't it?

The examples all demonstrate object modification, which has not been a
source of confusion, and all requests are for the exact number of
object instances that exist in a table of rows created at startup. The
examples fail to cover the cases of object creation/deletion or row
creation/deletion that have been areas of ambiguity.  

How does an NMS know that a new row has been created, and the NMS
should now set maxReps=3 rather than 2? How does the NMS know how many
changed rows to expect, or the maximum number to anticipate? Should an
NMS routinely set maxReps to a higher value than the expected number
of changed rows so it can detect the newly created rows? If the agent
response contains the exact number requested, should the NMS poll
again using the same syUpTime value with a higher maxReps to pick up
any not included in the previous Get* response? 

For example, assume row 3 is created at 500, and the GetBulk at 600
with foocounts=0 requests maxReps=2, then row 3 won't be included in
the response. How does the NMS know that row 3 exists? If it then
polls using GetBulk with foocounts.600, the creation of row 3 won't be
included in that response either. Right?

This is also a problem when an agent cuts short its processing of
GetBulk repetitions, as per RFC3416 4.2.3 in the discussion of
scenarios where fewer repetitions are returned than requested. To
capture any TimeFilter rows that should have been reported, the NMS
would need to repoll with the same sysUpTime value (with possibly a
shorter varbind list). This problem may not be reasonably resolvable,
but the text should make implementors/users/mib-designers aware of the
issue.

David Harrington
[email protected]






> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Wijnen, Bert (Bert)
> Sent: Tuesday, February 08, 2005 6:58 PM
> To: 'Andy Bierman'; [email protected]
> Cc: David Kessens (E-mail)
> Subject: RE: [RMONMIB] updated TimeFilter text
> 
> Do you think you can get this done before the ID- cutoff, so that
> my co-AD David can issue an IETF Last Call before the IETF?
> 
> Bert
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]On
> > Behalf Of Andy Bierman
> > Sent: Tuesday, February 08, 2005 18:01
> > To: [email protected]
> > Subject: [RMONMIB] updated TimeFilter text
> > 
> > 
> > Hi,
> > 
> > Here is the TimeFilter appendix, updated based on comments
> > from Dave Harrington.  Please review so we can get the I-D
> > updated.
> > 
> > thanks,
> > Andy
> > 
> 
> _______________________________________________
> RMONMIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rmonmib
>