Subject: Notification #9: replay in the future consensus point

From: Andy Bierman <[email-masked]>
Date: Wed, 08 Aug 2007 08:29:57 -0700

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 future

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.

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.

Andy

--
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: Balazs Lengyel <[email-masked]>
Date: Wed, 08 Aug 2007 18:08:57 +0200

Hello,
A) yes
B) yes
C) no

I proposed a set of simple rules.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Wed, 08 Aug 2007 09:32:18 -0700

> I proposed a set of simple rules.

      A          B           C            D
      +----------+-----------+------------+-----------

Log opens at time (A)
First log entry at time (B)
Second log entry at time (C)
<create-subscription> at time (D)

The actual values of startTime and stopTime are just
filter parameters.  Any startTime <= (B) will return
both logged entries.  If the stopTime is any time > (C)
then both entries are returned -- even if it > (D).

My concern (also raised by Randy) is that the agent
and manager clock skew will make it difficult for the
manager to give a value <= (D).

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 08 Aug 2007 18:37:30 +0200

>> I proposed a set of simple rules.
In this case better have a special value NOW. If C and D are very close due to the skew the 
manager might want to specify NOW, but might send down a stopTime < C.
Balazs

---

From: Andy Bierman <[email-masked]>
Date: Wed, 08 Aug 2007 11:06:15 -0700

Balazs Lengyel wrote:
> In this case better have a special value NOW. If C and D are very close 
> due to the skew the manager might want to specify NOW, but might send 
> down a stopTime < C.

I agree with you.
If there was a <now/> option, then it would be okay
to treat startTime and/or stopTime > 'now' as an error.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Aug 2007 21:08:06 +0200 (CEST)

> A) return an error if parameters are in the future

Better than B.

>    timestamps of entries in the log.

No, this seems very confusing.

>    Parameters refer to the 'time window' that notification

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.)

A special "now" value for the stopTime seems useful - it's like a
'cat' on the file.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 08 Aug 2007 12:28:28 -0700

>    the agent stop the notifications at a certain time.)

This really puts the "mode changes" issue front and center.
So stopTime in the future means "just stop sending notifications".
Does the session hang (waiting for session termination) or
does it silently revert to "normal mode" at the stopTime?

I've got to say, I've seen cleaner designs in my career.
This whole replay/live/termination/interleaving design is
really a mess.  The interleaving seems to be a big concern
to some people.  IMO, the manager MUST be able to send
at least a <close-session> operation.  I don't care as much
about interleaving because sessions are not that expensive.
But the <kill-session> termination mechanism and silent transitions
back into "normal" node or "hang" mode (like (D) above) are really a problem.

> A special "now" value for the stopTime seems useful - it's like a

It also supports the use case where the manager has code
that is designed to start listening to live notifications 'now',
and back-fill via a notification log (ala SNMP). (What? Use 2 sessions!)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Aug 2007 21:54:03 +0200 (CEST)

> does it silently revert to "normal mode" at the stopTime?

We already have the mode switch thing -- you always get a mode switch
if you use startTime and stopTime.

> really a mess.

I agree.

> The interleaving seems to be a big concern
> to some people.

To who???  I think most people are in favor of interleaving.

/martin

> IMO, the manager MUST be able to send

---

From: Andy Bierman <[email-masked]>
Date: Wed, 08 Aug 2007 13:17:39 -0700

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

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Aug 2007 22:41:06 +0200 (CEST)

> from sequence ID 'X' to sequence ID 'Y', via some Xpath filter,

This filter *is* different, because:

   1) if a start time is present, the agent should look in the log
   2) if a stop time is present, notification delivery is terminated by
      the agent and the session becomes normal again.

[But it didn't have to be different - if every event had a timestamp
(as in Sharon's original spec), you could have used the normal filter
mechanism, and let the agent implementor worry about optimizing away
the log search if the timestamp in the filter was late enough.

But if it was a normal filter, the agent would have to check the
stored notifications _unless_ the filter contained the
timestamp/sequenceID.  This is different from today where the default
(no start/stop time) means subscribe to live notifications only.

You would never get back to "normal mode" though.]

> that have not happened yet.

This also makes it different - the other filter applies to all
notifications, logged or live.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 08 Aug 2007 14:07:41 -0700

>       the agent and the session becomes normal again.

It started out simple enough, just trying
to model the "tail" and "tail -f" modes of
reading a log file.  The design seems to keep
straying away from that model.

> the log search if the timestamp in the filter was late enough.

IMO, this is part of a more general problem,
that should be solved by a separate RFC.

The 'eventClass', 'eventSeverity', and 'eventTime' fields
are meta-data which could be encoded as XML attributes
in the <notification> element.  This should be
required, even if the proprietary <eventType> has
some or all of these fields already.

This is why I keep asking the WG:
Are you SURE you want to forbid all XML attributes, forever,
from being included in the <notification> element?

Are you SURE this is not going to ever come up again
as an issue, because this is the only place we can
really put inter-operable meta-data into the notification message?

(All we need is an 'anyAttribute' clause in the <element>
definition...)

> notifications, logged or live.

What if the stopTime in the future happens before the agent
is done sending the replay notifications?
Does the agent stop, hang, revert to normal mode,
transition to a new mode?

That's why I want to keep it simple.

I guess I never liked the stopTime transition back to normal mode,
and it doesn't matter if it happens when the reply buffer is
empty or at some specified time 'X', after that.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Aug 2007 23:27:18 +0200 (CEST)

> is done sending the replay notifications?

Nothing special, since the stopTime just means that the agent is
supposed to send all notifications that were generated before that
time.  When that's done (whenever that happens) it reverts to normal
mode.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 08 Aug 2007 18:38:05 -0700

> time.  When that's done (whenever that happens) it reverts to normal

This seems like more trouble to implement
than it is worth.  I think I am not the only
one that does not see a need to expand the replay feature
into something that requires the agent to treat each corner
case differently.

The simple case -- the start to stop interval represents
log entries -- seems to be getting WG consensus.  I have not
heard much support for applying stopTime-in-the-future
as an additional mechanism to transition to live notifications
but stop after some of them.  I think WG consensus is
converging on the idea that the replay feature applies
only to logged entries that exist when the <create-subscription>
is received.

I also think WG consensus is converging towards allowing
interleaving.  I do not know yet if there is consensus
that an agent MUST support <close-session> in notification
mode, even if no other operations are supported.  I think
only one person wants to make sure the agent MUST NOT accept
any interleaved RPCs.  There seems to be consensus that
this option is not what the WG wants.  I think the "manager
SHOULD NOT send, and the agent MAY NOT process" language
is not inter-operable and does not allow for <close-session>.
This is very important text, so we have to keep working on it
until it is right.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 09 Aug 2007 09:34:29 +0200

Hello,
As we see it 'eventClass', 'eventSeverity','eventTime' and 'eventSender' are not meta-data but 
real data, they are essential and mandatory parts of every notification. I would really prefer 
them as elements instead of attributes. I can even foresee someone extending eventClass with a 
vendor specific evntSubClass.
On the other hand extensibility is good, so an anyAttribute does no harm.
Balazs

---

From: Andy Bierman <[email-masked]>
Date: Thu, 09 Aug 2007 04:14:57 -0700

Balazs Lengyel wrote:
> Hello,
> As we see it 'eventClass', 'eventSeverity','eventTime' and 'eventSender' 
> are not meta-data but real data, they are essential and mandatory parts 
> of every notification. I would really prefer them as elements instead of 
> attributes. I can even foresee someone extending eventClass with a 

Think about this statement.
If a vendor was to extend the standard definitions,
they would no longer be standard.  From an XML-PoV, these
extensions belong in the standard or vendor-defined <eventType>,
in a different namespace.

The value of 'fixed' standard fields is that they are fixed,
and a manager can count on them meaning what they are supposed to mean
across all agent implementations.

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 16 Aug 2007 07:27:56 -0400

<Andy>>
The 'eventClass', 'eventSeverity', and 'eventTime' fields are meta-data
which could be encoded as XML attributes in the <notification> element.
This should be required, even if the proprietary <eventType> has some or
all of these fields already.

This is why I keep asking the WG:
Are you SURE you want to forbid all XML attributes, forever, from being
included in the <notification> element?

Are you SURE this is not going to ever come up again as an issue,
because this is the only place we can really put inter-operable
meta-data into the notification message?
</Andy>

I don't consider these meta-data and it is only meta-data that you are
suppose to be using attributes for according to best practice I keep
hearing. These should be elements so I don't think there is an issue.

Sharon

---

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 16 Aug 2007 07:35:48 -0400

Hi

I'm not sure if this is helpful, but the original design we did of
replay, which I'm not sure was ever captured in any of the internet
drafts, was that a subscription was only either a replay subscription or
a real-time subscription. You got a replay by specifying startTime.
There was no stopTime as this was implicitly "now" for a replay
subscription (ie, the time the subscription was created). Not specifying
startTime gave you notifications as they happened. This is simpler, but
was also in a universe that supported interleaving and multiple
subscriptions per session.

Sharon

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Aug 2007 07:59:42 -0700

> subscriptions per session.

If you leave out the stopTime, then the agent sends all the
replayed notifications, followed by live notifications.
If stopTime is present, the agent reverts to normal mode
after the replayed notifications are sent.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Aug 2007 07:56:05 -0700

> hearing. These should be elements so I don't think there is an issue.

That's fine.
Leave the <notification> element such that nobody may ever
place an XML attribute there.  It can't be part of the filter anyway,
which starts at the next layer.

Note that there is no standard for 'eventClass', 'eventSeverity',
or 'eventTime', and a vendor may choose to use XML attributes
or elements for these fields (if they exist at all).

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Aug 2007 20:21:10 +0200 (CEST)

> or elements for these fields (if they exist at all).

The entire replay feature relies on the presence of an eventTime (or
similar).  If the manager can't figure out when the notifications were
generated, he cannot set startTime and stopTime to get missing
notifications.  IMO, it's a big mistake that this event time isn't
standardized - it means that a manager, in order to use replay
efficiently, has to know all datamodels of all notifications, and know
where to find the non-standard event time in each one.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Aug 2007 11:43:53 -0700

> where to find the non-standard event time in each one.

I agree.
It is a mistake to design the notification message assuming
these critical standard fields will be retro-fitted in
an inter-operable manner.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Aug 2007 21:54:19 +0200 (CEST)

> an inter-operable manner.

I'm implementing this draft right now, and there are a couple of
things that are awkward, but the main thing that makes it virtually
impossible to do a good implementation of the replay is the lack of
the eventTime (the time the notification was generated). 

In my manager, I want to be able to tell if I lost any notifications.
So I get all notifs from the log and maybe listen to the live feed.
If for any reason I can't listen to the live feed for a while, I try
to resync.  In order to do that, I use the replay feature with a
startTime equal to the generation time of the latest notification I
received.  But there is no standard way to get the generation time
from a notification.

I think that in order to make replay interopable, we need to add the
eventTime to the notifications.  Here are two small modifications to
the XSD that will allow this:

As an attribute:

  <xs:complexType name="NotificationContentType">
    <xs:attribute name="eventTime" type="xs:dateTime" use="required"/>
  </xs:complexType>

or as an element:

  <xs:complexType name="NotificationContentType">
    <xs:sequence>
      <xs:element name="eventTime" type="xs:dateTime"/>
    </xs:sequence>
  </xs:complexType>

Standard eventClass and eventSeverity would be nice, but they are not
crucial to the operations defined in the spec.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Aug 2007 20:07:25 -0700

> received.  But there is no standard way to get the generation time

I think this is a very important comment.
I don't see how anyone in the WG (or IETF for that matter)
can say that running code is not important to the standards process.
I would call the notification replay feature 'broken',
based on your comments.

>       <xs:element name="eventTime" type="xs:dateTime"/>

Which namespace would the 'eventTime' element be defined in?
Wouldn't it be different for every <fooEvent> element definition?
If it was an attribute in the <notification> element,
it would be in the same namespace as that element.

> crucial to the operations defined in the spec.

Furthermore, there is no agreement on what the enumerated strings
should be, or what semantics are associated with each string.
There is no disagreement at all that an event timestamp would
be encoded in xs:dateTime format.  This would the time the agent
generated the <notification> message, not any of the other
esoteric timestamps that have been discussed.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 17 Aug 2007 08:58:20 +0200 (CEST)

> Wouldn't it be different for every <fooEvent> element definition?

No.

> it would be in the same namespace as that element.

If it's defined the way I wrote above, the eventTime element is in
the same namespace as 'notification',
i.e. "urn:ietf:params:xml:ns:netmod:notification".  An example of an
notification on the wire:

  <ncn:notification xmlns:ncn="urn:ietf:params:xml:ns:netconf:notification:1.0">
    <linkUp xmlns="http://example.com/ns/interface">
      <ncn:eventTime>2007-08-17T08:56:05</ncn:eventTime>
      <ifIndex>3</ifIndex>
    </linkUp>
  </ncn:notification>

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 17 Aug 2007 11:13:07 -0700

Attn WG:

Are there any objections to adding 'eventTime' to the notification
message, as described by Martin?

Andy

---

From: "tom.petch" <[email-masked]>
Date: Mon, 20 Aug 2007 12:20:08 +0200

----- Original Message -----
From: "Andy Bierman" <[email-masked]>
To: "Martin Bjorklund" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, August 17, 2007 8:13 PM
Subject: Re: Notification #9: replay in the future consensus point

> message, as described by Martin?

I prefer the <element> option since I think it gives simpler XPath expressions
for filtering.

Tom Petch

> >   <ncn:notification
xmlns:ncn="urn:ietf:params:xml:ns:netconf:notification:1.0">

---

From: Andy Bierman <[email-masked]>
Date: Mon, 20 Aug 2007 16:46:21 -0700

David B Harrington wrote:
> Hi,
> 
> I would recommend adding fields akin to severity and facility as well.

The WG tried but did not come close to agreeing on all the
enumerations.  The WG agreed this was a "content" issue.
The WG does not agree that the notification mechanism
is directly mapped to syslog.

What is the severity and facility for a "linkUp" or "linkDown" event,
for example?

> dbh 

Andy

> 
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Andy Bierman
>> Sent: Friday, August 17, 2007 2:13 PM
>> To: Martin Bjorklund
>> Cc: [email-masked]; [email-masked]

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 20 Aug 2007 19:14:27 -0400

Hi,

dbh

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 22 Aug 2007 08:44:36 -0400

Hi

Two comments on this. Our implementation has eventTime for many of the
reasons discussed. I support inclusion of eventTime as an element in the
notification.

Sharon 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, August 16, 2007 11:07 PM
To: Martin Bjorklund
Cc: Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: Re: Notification #9: replay in the future consensus point

Martin Bjorklund wrote:
>>>> or 'eventTime', and a vendor may choose to use XML attributes or 
>>>> elements for these fields (if they exist at all).

>>> similar).  If the manager can't figure out when the notifications 
>>> were generated, he cannot set startTime and stopTime to get missing 
>>> efficiently, has to know all datamodels of all notifications, and 
>>> know where to find the non-standard event time in each one.
>> I agree.
>> It is a mistake to design the notification message assuming these 
>> critical standard fields will be retro-fitted in an inter-operable 
>> manner.
> 

I think this is a very important comment.
I don't see how anyone in the WG (or IETF for that matter) can say that
running code is not important to the standards process.
I would call the notification replay feature 'broken', based on your
comments.

Which namespace would the 'eventTime' element be defined in?
Wouldn't it be different for every <fooEvent> element definition?
If it was an attribute in the <notification> element, it would be in the
same namespace as that element.

> crucial to the operations defined in the spec.

Furthermore, there is no agreement on what the enumerated strings should
be, or what semantics are associated with each string.
There is no disagreement at all that an event timestamp would be encoded
in xs:dateTime format.  This would the time the agent generated the
<notification> message, not any of the other esoteric timestamps that
have been discussed.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 27 Aug 2007 14:01:12 +0200

Hello,
I support inclusion of eventTime as an element in the
notification.

Balazs