Martin Bjorklund wrote:
Andy Bierman <ietf@andybierman.com> wrote:Hi, I would like people to speak up about the startTime and/or stopTime parameters in the future issue. Do you favor: A) return an error if parameters are in the futureBetter than B.B) return whatever the agent has in its reply log that matches the search criteria (at the time the request is made). Parameters only refer to the timestamps of entries in the log.No, this seems very confusing.C) treat as a request to start returning notifications some time in the future, according to the parameters. Parameters refer to the 'time window' that notification delivery is desired.I can live with it, but I don't prefer it. I'd prefer: D) treat startTime in the future as an error, but stopTime in the future is ok (it's like giving a startTime w/o a stopTime, but let the agent stop the notifications at a certain time.)
IMO, this filter is not special. It is no different than retrieving all the log entries from sequence ID 'X' to sequence ID 'Y', via some Xpath filter, The filter applies to the data in the log, not notifications that have not happened yet. <project-manager-hat-on> I don't want to let the Engineers introduce more features into this release. The "must-haves" for this feature are: 1) retrieve the logged notifications with start and stop parameters (if requested) 2) transition to live notification delivery after replay (if requested) 3) terminate the session cleanly w/ <close-session> Everything else is redundant, and therefore not a "must-have" feature. </project-manager-hat-on>
A special "now" value for the stopTime seems useful - it's like a 'cat' on the file. /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/>
-- 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/>