Notification + Yang-push Kickoff 26 - April

Attendees (i.e., potential authors) Andy Bierman – YumaWorks Sharon Chisholm – Ciena Alexander Clemm – Cisco Einar Nilsen-Nygaard – Cisco Yan Gang - Huawei Alberto Gonzalez Prieto – Cisco Hector Trevino – Cisco Ambika Prasad Tripathy – Cisco Eric Voit – Cisco Kent Watsen – Juniper Guangying Zheng (Walker) – Huawei

Interests and Objectives What do each of us consider success? Sharon: Relationship with existing RESTCONF notification mechanisms Andy: Modularity so that solutions can be used/reused for different protocols. From SDN to IOT to COAP. Keep transport, encoding modularized. Kent: High Throughput support (Control & data plane), backwards compatibility, OpenConfig & I2RS. Einar: +1 w/ Andy & Kent goals. Alex: +1 w/ Andy & Kent goals. Streaming updates is main objective, but modular Yan: Performance in an SDN scenario (reaction speed & volume) Walker: design of Notifications and support of new capabilities, ensure full functionality Hector: evolution of NETCONF Notifications and Data Model separation. Coverage of Operational side. Ambika: +1 w/ Andy & Kent goals. Modular, flexible, high throughput. Multi-tenancy. Eric: +1 w/ Andy & Kent goals. Add in: native HTTP transport, micro-subscriptions.

Assumptions Everything is negotiable, assuming objective is under NETCONF charter No assumption that existing drafts drive final result IF/WHEN we get consensus on functional partitioning, fodder from existing drafts and other attendee materials should be applied as starting point (if applicable) Attendees can be on zero-to-all drafts (tbd based on previous + new contribution.) Must support 5277 backwards compatibility (note: this was revisited later in the call)

Subscription Mechanism: 1. YANG Datastore Push 2. Subscriptions for Event Notifications Choice of Transports: 3. NETCONF Transport for Event Notifications 4. RESTCONF Transport for Event Notifications Future Transport Notification drafts Strawman functional partitioning context (as discussed at IETF95) Discussion: Is this a reasonable starting point? (expecting lots of iteration on boundaries as this evolves.)

Strawman Functional Partitioning Context (overlaid with IETF95 authors’ mental model) Event NotificationsYANG Datastore Push 5277 ModeEnhanced Types of SubscriptionDynamicDynamic and Static Subscriptions per Session onemany NegotiationNoYes RPCscreateestablish, modify, delete Control Plane NotificationsNone started, suspended, resumed, terminated, modified Data Plane Notificationsnotification+subscription-id push-update, push-change-update NETCONF Yes RESTConf, HTTP, HTTP2No Yes Subscription Transport YANG Datastore Push Subscriptions for Event Notifications NETCONF Transport for Event Notifications RESTCONF Transport for Event Notifications Legend Compatibility with RFC-5277

Subscriptions for Event Notifications (Base Subscription Draft) Support for many subscriptions / transport Dynamic & Static state machines Stream discovery New stream types (syslog?) Authorization model per stream RFC5277 & XPATH filters RPCs: Establish, modify, delete Error responses (under error-info?) Notifications: started, suspended, resumed, terminated, modified YANG Datastore Push (includes functions above Base Subscription Draft): Datastore on-change and periodic triggers YANG filters per RFC6241 Authorization model per object NETCONF Transport for Event Notifications Transport mapping 5277 mode RESTCONF Transport for Event Notifications Transport mappings (incl. HTTP2) Subscriber/receiver different Heartbeats and clean-up Subscription to HTTP2 stream Out of Scope/future: dynamic stream creation, new undefined filter types Strawman Functional Partitioning Context (more details on authors’ mental model) Negotiation Stream configuration & stuff Data Plane Notification 5277 mode & YANG model Multiple static receivers Replay (by Stream type) Prioritization Monitoring Push-update, Push- change-update New stream types & stuff

Draft, document, and issue repository Github repository corresponding to each partitioned context YANG Datastore Pushupdate-push Subscriptions for Event Notificationsnotification-sub Netconf Transport for Event Notificationsnotification-netconf Restconf Transport for Event Notificationsnotification-restconf Exposure of issues so all in WG can track. Any Common terminology, context, and supporting materials maintained in a single Github Repository – Recommend “Subscriptions for Event Notifications” Other suggestions/tools to use?

Strawman Terms Page 1 TermDefinitionSource (and deviations) Data NodeAn instance of management information in a datastore. Effectively the same as But 6020 uses terms not contextually relevant here: “A node in the schema tree that can be instantiated in a data tree. One of container, leaf, leaf-list, list, and anyxml.” Data Node Update A data item containing the current value/property of a Data Node at the time the Data Node Update was created. Dynamic Subscription A Subscription negotiated between Subscriber and Publisher via create, establish, modify, and delete RPC control plane signaling messages. Superset of 5277 definition of “Subscription”: “An agreement and method to receive event notifications over a NETCONF session. A concept related to the delivery of notifications (if there are any to send) involving destination and selection of notifications. It is bound to the lifetime of a session.” Datastore A conceptual store of instantiated information, with individual data items represented by Data Nodes which are arranged in hierarchical manner. Effectively the same as If needful, we could adopt this text “A conceptual place to store and access information. A datastore might be implemented, for example, using files, a database, flash memory locations, or combinations thereof.” Event An occurrence of something that may be of interest. (e.g., a configuration change, a fault, a change in status, crossing a threshold, status of a flow, or an external input to the system.) Effectively the same as 5277 “Event” “An event is something that happens that may be of interest - a configuration change, a fault, a change in status, crossing a threshold, or an external input to the system, for example. Often, this results in an asynchronous message, sometimes referred to as a notification or event notification, being sent to interested parties to notify them that this event has occurred.” Event Notification A set of information intended for a Receiver indicating that one or more Event(s) have occurred. Details of the Event(s) may be included within the Notification. Somewhat embedded within the 5277 “Event” description see above Event StreamA continuous, ordered set of Events grouped under an explicit criteria. Superset of 5277 definition of “Stream” “An event stream is a set of event notifications matching some forwarding criteria and available to NETCONF clients for subscription.”

Strawman Terms Page 2 TermDefinitionSource (and deviations) Filter Match criteria which may be applied against an Event Stream. A specific Event Notification traverses the Filter only if specified Filter criteria are met. Information within that Event Notification may also be excluded based on additional match criteria within the Filter. Superset of 5277 definition of “Filter” “A parameter that indicates which subset of all possible events are of interest. A filter is defined as one or more filter elements [NETCONF], each of which identifies a portion of the overall filter” Notification The communication of an occurrence, perhaps triggered by the occurrence of an Event. PublisherAn entity responsible for streaming Event Notifications per the terms of a Subscription. Receiver A target to which a Publisher pushes Event Notifications. For Dynamic Subscriptions, the Receiver and Subscriber will often be the same entity. Static SubscriptionA Subscription installed via a configuration interface. Subscriber An entity able to request and negotiate a contract for the receipt of Event Notifications from a Publisher Subscription A contract between a Subscriber and a Publisher stipulating which information the Receiver wishes to have pushed from the Publisher without the need for further solicitation. Superset of 5277 “Subscription”: An agreement and method to receive event notifications over a NETCONF session. A concept related to the delivery of notifications (if there are any to send) involving destination and selection of notifications. It is bound to the lifetime of a session. Subscription PolicyA policy that specifies under what circumstances to create an Event Notification. Update Notification An Event Notification including those Data Node Update(s) to be pushed in order to meet the obligations of a single Subscription. All included Data Node Updates must reflect the state of a Datastore at a snapshot in time. Update Stream A conceptual Event Stream that streams the contents of an entire Datastore continuously and perpetually. Update TriggerA trigger, as specified by a Subscription Policy, that determines when a Data Node Update is to be communicated. (e.g., a change trigger, invoked when the value of a Data Node changes or a data node is created or deleted, or a time trigger, invoked after the laps of a periodic time interval.)

Discussions Thoughts on the partitioning context. Are we ok with each mapped to a strawman draft? Who wants to be involved in which areas? How to we structure meetings going forward? – Weekly by draft ? – Bi weekly cross-draft get-togethers/reviews?