Re: [Netconf] #14: notification termination mechanism considered dangerous

[Andy Bierman <ietf@andybierman.com>]

Sharon Chisholm wrote:
>  
>
> <Andy>
>
> One really valid option, raised by Phil, is to just close the session
> normally (as if the <create-subscription> was followed by a
> <close-session>) after replay w/stopTime is complete. Problem solved.
> The agent never 'sees' any new <rpc> because the <close-session> is
> implicitly ahead of it in the queue.
>
> <Andy>
>
> That's an unexpected side-effect and not terribly pretty. I think the
> current behaviour of just not reading the requests until stopTime makes
> the most sense.


The real issue is the interpretation of the filter which is
specified by startTime and stopTime.

I think there is WG consensus that this filter only applies
to logged entries, not notifications in the future that have
not happened yet.  Are you challenging this WG consensus?

Whether the notifications are stored with sequence IDs or
timestanps makes no difference.  If there are notifications numbered
4, 5, and 6 in the replay log, and I ask "Give me all the
stored notifications from 1 to 10", this still just returned
4, 5, and 6, sends replayComplete, and is done.

It doesn't mean "Send 4, 5, 6, and wait (maybe forever)
until notifications 7 - 10 are generated."

So stopTime in the future is not an error -- it is just the upper
bound on the set of stored notifications.


> Sharon 

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