Stream Issues Alex, Ambika, Eric, Tim Definition and domain of basic set of Stream types. What streams are provided and what do they contain (includes default 5277 stream). We will need a new stream type defined for I2RS. Do we need extra filter types for I2RS duplicate writes? (Is this effort defining new filter types and specifics for I2RS protocol?) Stream discovery. Are adjustments needed for maximal transport independence? Replay support will be provided for selected stream types (modify vs. delete) Which stream types to introduce? Current list includes streams for all operational and for all config data. Consider adding stream for operational data minus counters. Also: assess implications of opstate implications on required data streams. In addition to identifying which items go to which streams, identifying and calling out which items (such as counters) should not be "on-change subscribable" may be useful. Consider introducing a Yang extension to define if an object: is-a-counter and/or not-notifiable. Implications of ephemeral requirements from I2RS Stream discovery. Adopted mechanism in 5277-bis and include backwards compatibility support. Integration specifics for Restconf capability discovery on different types of Streams

Streams from Datastores Publisher Event Notification Generation … Subscription 1 Subscription 2 Subscription n Event Stream Generation NETCONF Legacy Running Config Counters Operational Status Intended Config Operational State Running Config System State Startup Config Candidate Config Ephemeral Config Persistent Config Applied Config System Config Counters Operational Status Syslog Flows draft-wilton-netmod-refined-datastores-01 Telemetry sources OS APIs NOS APIs HW APIs CLIshow MIBs IPSLA Routes syslog traffic sensor Netflow Existing stream YANG Push stream Anticipated future stream

Layered Subscription Framework IETF Common Open Config Application (OSS, Controller) Subscriber Recipient Static Dynamic Publisher Subscription Mgmt Update Packaging and Flow Control Transport Session TLS SSH HTTP HTTP2 Update Packaging and Flow Control Mgmt RFC5424 gRPC Restconf Netconf Static Dynamic Encoding Thrift GPB JSON XML Syslog IPFIX ASN.1 BER TDL JDBC YANG YANG Event Notification Generation Mgmt Event Notification Generation Access Control Filtering Analytics Enrichment Reasoning Event Stream Generation Event Stream Generation Mgmt Config Operational Flows Dynamic Static Persistent Ephemeral Routes Events Status Counters Measures Traffic Sensor Data Source Mgmt Telemetry sources OS APIs NOS APIs HW APIs CLIshow MIBs IPSLA Routes syslog traffic sensor Netflow

QoS Issues Ambika, Eric Detecting loss of a sequential update notification, and mechanisms to resend. Implications to transports must be thought through. An ETag is an opaque identifier assigned by a web server to a specific version of a resource found at a URL. If the resource representation at that URL ever changes, a new and different ETag is assigned. Do we want an entity tag MUST be maintained for the root of any subscription? Should this allow correlation across independent subscriptions? Should this be transport independent? What QoS parameters should be supported for subscriptions? Note: QoS parameters are applicable to buffering as well as temporarily loss of transport connectivity. NEW: Sequencing across Subscriptions with RESTCONF (different Subscription requests made to different streams?)

QoS Requirements, YANG Push (RFC 7923) Green = relevant to RFC 5277bis Liveliness MUST be able to respond to requests to verify the Liveliness of a subscription. MUST be able to report the currently monitored Nodes of a subscription Dampening MUST be able to negotiate the minimum time separation since the previous update before transmitting a subsequent update Reliability For a particular subscription, every update to a subscribed object MUST be sent to the Receiver in sequential order Coherence MAY send Updates over Best Effort and Reliable transports. Presentation MAY have the ability to bundle a set of discrete object notifications into a single publishable update for a subscription. A bundle MAY include information on different Data Nodes and/or multiple updates about a single Data Node. For any bundled updates, MUST provide information for a Receiver to reconstruct the order and timing of updates Deadline MUST be able to push updates at a regular cadence that corresponds with specified start and end timestamps Push Latency MUST be possible to determine the time between object change and actual Push Relative Priority SHOULD support the relative prioritization of subscriptions so that the dequeuing and discarding of push updates can consider this if there is insufficient bandwidth

Relative Prioritization Context (YANG Push only) Device Publisher subscription-priority (8bit integer, optional) priority of a subscription subscription-dependency (string, optional) points to single parent subscription Subscription Subscription Subscription Stream multiplexing Stream prioritization Flow control, per–stream Flow control, per–TCP HTTP2 Client Weight (8bit integer) enables proportional bandwidth when there are multiple streams to same TCP Peer Stream Dependency (31bit integer) preempts the marshalling of updates for any dependent streams Stream Stream Stream TLS Device Device (re)Transmit frames at rate consumable into destination TCP Prioritize and rate shape IP Subscriber Subscriber Dequeue Phys

OAM Issues Alex, Balazs, Sharon Mechanisms for diagnostics, e.g. deal with dropped updates, monitoring when they occur, etc. Test-only option for a subscription is desired. But it still needs to be defined.