RE: updated TimeFilter text

At 05:29 PM 2/8/2005, David B Harrington wrote:
>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?

I thought that text was confusing.  There is already text that says
some agents will return duplicates (different only in TimeMark value).
It seems redundant to say again that if the agent is in this mode
then a GetBulk will contain these returned values, and duplicates
will probably be present.


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

typo -- I'll change it back


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

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.  


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

send text if you have it.  I don't see how this is a TimeFilter specific 
issue.


>David Harrington
>[email protected]

Andy








>> -----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
>> 
>
>
>
>_______________________________________________
>RMONMIB mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmonmib