Operating System: Linux
Platform: Other

Attachment eventTime_logs_and_generated_pojo.zip has been added with description: Karaf logs and generated POJO classes from the yang model

I do not believe this is either a yangtools not an mdsal codegen issue.

To elaborate, 'notification' defines a YANG notification, which is the contents of the event, not its metadata (like eventTime, which really is NETCONF-specific metadata).

Can you describe the specific use case?

RFC 5277 mandates eventTime to be part of every notification content and it is not merely metadata.

My use case was to be able to subscribe for NETCONF notifications and further process/act upon based on the severity.

--------------------------------------------------------------------------
Excerpt from RFC 5277

2.2. Sending Event Notifications

Once the subscription has been set up, the NETCONF server sends the
event notifications asynchronously over the connection.

2.2.1. <notification>

Description:

An event notification is sent to the client who initiated a
<create-subscription> command asynchronously when an event of
interest (i.e., meeting the specified filtering criteria) has
occurred. An event notification is a complete and well-formed XML
document. Note that <notification> is not a Remote Procedure Call
(RPC) method but rather the top-level element identifying the one-
way message as a notification.

Parameters:

eventTime

The time the event was generated by the event source. This
parameter is of type dateTime and compliant to [RFC3339].
Implementations must support time zones.

Also contains notification-specific tagged content, if any. With
the exception of <eventTime>, the content of the notification is
beyond the scope of this document.

--------------------------------------------------------------------------

Right, but RFC5277 is NETCONF notifications, not YANG notifications. Codegen works on top of RFC6020/7950, without access-protocol-specific metadata.

Hi Robert,

I was looking into the code,
When ODL receives netconf notification it will be of type NetconfMessage.
NetconfMessage has <eventTime>2017-10-26T21:41:54Z</eventTime>. From NetconfMessage there will be an instance of DOMNotification will be created.

Class NetconfMessageTransformer {
static class NetconfDeviceNotification implements DOMNotification, DOMEvent

}
In DOMNotification, eventTime is separated from content. The content will be delegated to corresponding NotificationListener with the help of schemaPath. EvenTime will never be delivered to listener since its not part of content. So is there any way in which eventTime is also delivered to the NotificationListener along with content?

Right, because that is a detail is part of metadata, not the actual notification data. I am not sure how to map this – perhaps RFC7952 is part of the solution, somehow. Sorry, I do not have this problem domain loaded, so cannot really wrap my mind about end to end implications

After thinking about this a bit more, there are essentially two approaches we can take:
1) transport notification metadata at the NotificationBroker level, add another argument to all NotificationListener interfaces
2) transport notification metadata in-band, e.g. add DataContainer.metadata(), which exposes access to metadata

In either case we need to generate container classes for each md:annotation use in models, such that metadata type is properly captured (yangtools.rfc7952.model.api.Annotation gives us everything we need).

I think I like approach 2) better, as it allows for proper forwarding without losing metadata.

Also, we need someone to define event-time annotation – I am not sure if there is an IETF RFC/draft that does that.

Karthik, for now I'm assigning this to you.

Please decide update who should handle this issue. 

Actually  eventTime is not metadata, nor should it be attached to the notification directly, as it is data from the "Messages" layer of NETCONF, https://tools.ietf.org/html/rfc6241#section-1.2 , hence it is part of notification envelope.

From that perspective option 1) is correct, as there are two distinct cases here:

1. the notification is being generated, and therefore eventTime needs to be generated by the NotificationBroker
2. the notification is being forwarded, and therefore eventTime needs to be propagated from the original envelope

The envelope approach is interesting in that an envelope can actually contain more than eventTime and 2) may want to modify other things (like record forwarding).

I think we should take a lesson from DOM world here, where DOMNotification and DOMEvent are completely separate interfaces composed by implementation. The same approach can be taken in Binding world, where we lack the equivalent of DOMEvent – which should be defined in Binding API, not binding spec, let's say EventInstantAware. The design of that interface needs to take into account the binding spec and its method must not overlap with user-generated methods (hence no 'get' method prefix!).

binding-dom-adapter would be tagging incoming Notification instances with current time, forwarding them to DOMNotificationRouter as proper DOMEvents, by subclassing  LazySerializedDOMNotification. On the receiving end, binding-dom-codec needs to grow a subclass of LazyDataObject, which will, in addition to the normal interface, implement EventInstantAware.

Users can then query their incoming notifications for EventInstantAware, and if it is available it will be presented to them.