Subject: NETCONF Events: Pre-release 3

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 10 Sep 2007 10:33:09 -0400

Hi

Attached is the pre-release of version -09 of NETCONF notification
draft. I plan to submit by close of business my time today. Please send
any reports of typos, gating issues, etc ASAP.

Thanks,

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 10 Sep 2007 21:20:12 +0200 (CEST)

Hi,

Some quick comments on the larger issues.

> any reports of typos, gating issues, etc ASAP.

I noted that you did not define the :interleave capability.

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 10 Sep 2007 20:27:52 -0400

Hi

<Martin>

</Martin>

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

<Martin>

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Sep 2007 18:32:00 -0700

> 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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Sep 2007 10:49:04 +0200 (CEST)

> only notifications with eventTime values up to that time).

That was my understanding as well.  How do we proceed from here?

> if the stopTime is considered to be min(stopTime, now).

Right, since <replayComplete> covers this this.  I.e. *if* we don't
support stopTime in the future, and the manager sets a stopTime, when
he gets <replayComplete> he knows that the session is back to normal
mode.  <notificationComplete> is needed only when stopTime in the
future is supported.

/martin

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 11 Sep 2007 07:08:51 -0400

Hi

Ok. I think these are useful features, I just thought there was
consensus to defer. I did go ahead and submit -09 last night since it
has been a long time in the making. I'll start edits for a -10 with
these changes, which, if we agree on the details of these modifications,
should come out in a few days or so.

Sharon  

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, September 10, 2007 9:32 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: Martin Bjorklund; [email-masked]
Subject: Re: NETCONF Events: Pre-release 3

> 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

> 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 [email-masked] with the

> word 'unsubscribe' in a single line as the message text body.