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

[Andy Bierman <ietf@andybierman.com>]

Martin Bjorklund wrote:
> 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 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.

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

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.


> Standard eventClass and eventSeverity would be nice, but they are not
> 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.

> /martin

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