Martin Bjorklund wrote:
"Sharon Chisholm" <schishol@nortel.com> wrote:Hi Fair enough. It does allow you to tell the difference if the start time is 1pm, you asked for 2pm, and the first notification replayed was from 2:30. We could change it to be the timestamp of the start of the log which handles both cases.So you want the value to be the timestamp of the first notification in the log if any notifications are present, and log creation time otherwise? That would work, but more descriptive text that "start of log" is needed.And did people only want this object present when replay is supported on that stream?Yes.
So: capability #notification set means the <create-subscription> operation will be accepted. capability #replay set means the startTime and stopTime parameters will be accepted. replayLogStartTime set means there is a replay log. Capability #replay set but no replayLogStartTime means that the completely proprietary replay log collection control setup has not been done. Since there are no standard controls over the size and start time of the replay log, this timestamp object is the read-only indication of any replay config changes, plus an indication of the implied 'delete-oldest-first' garbage collection activity.
/martin
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/>