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

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

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

4. 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?)

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

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

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