Simon Leinen wrote:
I don't expect anybody to listen, but here's my take on
replayLogStartTime from the point of view of an operator.
As an operator, what I'm interested in is the temporal extent for
which the record of notifications in the buffer is complete. Assuming
the end of that extent is "now", the ("start") time I need is either
* the time the buffer was created and started recording notifications,
or,
* if notifications already had to be dropped, the time of the most
recent notification that had to be dropped.
But since everybody else on this list is an implementor, you will
simply ignore this as overly complicated/hard to implement.
I don't think we are ignoring comments. This is the first time you brought up this requirement. I don't think replayLogStartTime was added with much WG discussion at all, so it is not surpising that there is not much agreement on how it works, or even why it is needed. I would prefer that the replayLogStartTime not change constantly, but people seem to want to use it to optimize the startTime parameter. You are describing some different, more traditional data objects. Following good MIB design practices, one would likely put a replayLastDroppedTime type of object in the MIB module. Then one might discover that drops before the log are also interesting and we should monitor that event as well. Andy -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/>