[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NETCONF Events: Pre-release 3

Sharon Chisholm wrote:

Hi


I think there was consensus for the interleave capability
and for stopTime in the future indicating the time in the
future to stop listening to notifications (i.e., deliver
only notifications with eventTime values up to that time).

There is no point to a 2nd event (notificationComplete)
if the stopTime is considered to be min(stopTime, now).

Andy



<Martin>

I noted that you did not define the :interleave capability.
</Martin>

I didn't think there was consensus to do this now. It is certainly no
precluded.

<Martin>
You define <replayComplete> and <notificationComplete>, in order to
properly handle the case where the stopTime is in the future.  But you
also write

        A stop times that is later later than the current time, will
	be interpreted as being the time of the subscription creation
	(current time).

Was this intentional or just a left-over from previous edits?

If we don't want to do stopTime in the future, the
<notificationComplete> notification is meaningless.

I thought we agreed to support stopTime in the future.
</Martin>

My understanding was that consensus was to not allow stopTime in the
future. The text you quoted precludes stopTime in the future while
providing a way to say "now" without creating some weird data type. It
means the clocks between the server and the client don't need to be
synchronized.

NotificationComplete still tells you when the last notification has been
sent and the session is transitioning back to being interactive, which
is helpful.


Sharon


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