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

[Martin Bjorklund <mbj@tail-f.com>]

Andy Bierman <ietf@andybierman.com> wrote:
> Martin Bjorklund wrote:
> > Andy Bierman <ietf@andybierman.com> wrote:
> >> 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).
> > 
> > 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.
> 
> 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'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

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