Minutes 2017 01 11

Meeting Materials	Attending
WebEx Recording password: hSv7ubF4	Andy Bierman, Alexander Clemm, Ambika Tripathy, Einar Nilsen-Nygaard, Eric Voit, Tim Jenkins, Balazs Lengyel, Mehmet Ersue, Alberto Gonzalez

(to-be-renamed) 5277bis and NETCONF charter

Since April we have been generalizing Yang-push's control plane so that it works for general notifications on any transport. For a complete solution, this team also believes we should work out the data plane notification issues. There are enough technical changes that we don’t think that enhancing 5277 is an appropriate anymore.
Mehmet has reviewed communications on NETCONF, and seen that no one is advocating for the “Enhancing 5277” path which is currently reflected in the charter.
Mehmet will be sending a charter request email to NETCONF to see if we want to add Notifications 2.0 to the charter.
If yes, then Notifications 2.0 needs to be defined, and we need to finalize the discussion on the work split and the drafts. My guess is that in addition to the current four drafts, we would have a separate one specific to notifications.
If no, then we would still need the data plane work for yang-push notifications, and something specific to it would reside in that draft. Beyond that, the current 5277bis can’t be stand-alone, and the control plane generalized there would be re-folded back into yang-push.
Obsoleting or non-obsoleting 5277 is an Orthogonal question which can be addressed at a later date.

Time to put our issues onto Github so that the rest of the WG can track. At this point, the issues are:

Error types scrubbing (Alex)
Data plane notifications and layered headers (Andy)
How to allow for seamless integration with non-standard encodings and transports (like GPB/GRPC). (Eric)
Revisit Charter of NETCONF for Notification 2.0 (Mehmet)
Breakdown of draft structure (Eric)
Subscription ID and Security (Eric)
Not-notifiable-on-change (Balazs)

We will house issues which span more than one draft (and all above do this) here

Andy talked about new capabilities which might be useful
Must be extensible to allow new header information and new transports
Should explore bundle multiple subscription (or other) notification messages into a single pushed notification
Would be nice to limit the number of data plane update messages sent to a receiver per second across subscriptions
Identifier for previous notification to help the receiver discover whether we lost the previous one somehow.
Eric to aggregate requirements. Where in the different drafts do things have to change

Notifiable or not-notifiable extensions both seem necessary. Plus we want inheritance under a subtree for either not-notifiable or notifiable extension.
At this point, we won’t use an annotation
New information will be place outside the main model
Need to address ways of having platform sourced yang data available off-line for developers
Should we do this via instance data or model data? Balazs will frame something which goes to the NETCONF WG.