Issues for the 4 drafts – v 23June2016
Tags / SubteamStream / Alex, Ambika, Eric, Tim
Filter / Alberto, Alex, Sharon, Eric
QoS / Ambika, Eric
OAM / Alex, Balazs, Sharon
Encoding / Andy, Kent, Balazs
Transport / Andy, Kent, Balazs
On-change / Alberto, Alex, Andy, Kent, Tim
Configured / Alberto, Andy, Kent, Tim
Compatibility / Sharon
I2RS / Susan
Document / (Authors of a particular draft)
Legend
Status / Row Color
Unaddressed
Agreement in Principal
Closed
5277bis
Issue / Tags / Lead / Issue / Next stepEN1 / Stream / Alex / Definition and domain of basic set of Stream types. What streams are provided and what do they contain (includes default 5277 stream).
o 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?)
EN2 / Filter,
Stream / Clarify interplay between filter definitions and different streams. Includes information in subtrees of event payloads.
EN3 / OAM / Mechanisms for diagnostics, e.g. deal with dropped updates, monitoring when they occur, etc.
EN4 / Encoding, Transport / How to allow for seamless integration with non-standard encodings and transports (like GPB/GRPC). Specify requirements encoding and transport must meet, provide examples.
EN5 / Compatibility / Along with Netconf-notif, should this draft obsolete 5277 or be in parallel with it?
EN6 / Stream / Stream discovery. Are adjustments needed for maximal transport independence?
EN7 / QoS / Eric / Detecting loss of a sequential update notification, and mechanisms to resend. Implications to transports must be thought through.
EN8 / Transport / Should we have a mandatory transport?
EN9 / Configured / Multiple receivers per Configured Subscription is ok
EN10 / Stream / Replay support will be provided for selected stream types (modify vs. delete)
EN11 / Security / Required layering security requirements/considerations will be added into the YANG model for Configured Subscriptions. It will be up to the transport to meet these requirements.
EN12 / OAM / Test-only option for a subscription is desired. But it still needs to be defined.
EN13 / Filter / RFC6241 Subtree-filter definition in 5277bis cannot apply to elements of an event. Must explicitly define how 6241 doesn't apply filtering within a 5277bis event.
EN14 / Document / Ensure that Configured Subscriptions are fully defined in YANG model.
EN15 / Document / Term for Dynamic and Static Subscriptions (move to "Configured")
EN16 / Document / move Subscription ID in Notification to this document from Yang-push
EN17 / QoS / 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?
Yang-push
YP1 / Stream / 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.
YP2 / Stream,
Filter / 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.
YP3 / QoS / What QoS parameters should be supported for subscriptions?
· Note: QoS parameters are applicable to buffering as well as temporarily loss of transport connectivity.
YP4 / I2RS,
Stream / Implications of ephemeral requirements from I2RS
YP5 / Filter / Filters: YANG 1.1 allows filters to be defined in multiple places. How do they intersect each other in a deterministic way.
YP6 / On-change / Ambika / On-change subscription: consider providing publisher with capability to initiate a refresh of contents rather than send deltas. Current proposal allows for a "synch-on-start" option; such an option might be useful also e.g. on resumption of a subscription that had been suspended.
YP7 / Security,
Filtering,
Negotiation / Do we need an extension for NACM to support filter out datastore nodes for which the receiver has no read access?
· how does this differ from existing GET, which must do the same filtering?) In 5277, such filtering is done at the notification level. Yang-push includes notification-content filtering. This may be very expensive in terms of processing. Andy suggestion: only accept Yang-push subscriptions for subtrees the user has rights for all the nodes in the subtree. Changes to those rights trigger a subscription termination. Should we codify this, or let vendors determine when per subtree filtering might be applied?
YP8 / Configured / Multiple receivers per configured subscription is ok.
YP9 / On-change / Proper behavior for on-change, including detecting and indicating changes within a dampening period.
· Open: do we add a counter for the number of object changes during a dampening period?
YP10 / Negotiation / Negotiate vs. auto-adjust. Cases where negotiate is needed exists for domain synchronization. Error messages can be used to transport information back as hints. Alternative is dedicated RPC responses. In either case specific contents of these negotiation messages must still be defined.
YP11 / Document / Message format for synchronization (i.e. synch-on-start) still needs to be defined.
YP12 / Document / Periodic interval goes to seconds from timeticks
YP13 / Document / Balancing Augment vs. Parallel Model structures (maximize augment)
YP14 / Document / Moving from separate start/stop to Anchor time for Periodic
Notif-netconf
Issue / Tags / Subteam / Issue / Next stepNT1 / Compatibility / Support multiple create-subscriptions over a single NETCONF session? or only multiple establish-subscription?
· Recommend only establish-subscription anytime there may be more than one subscription, otherwise variations of supported RFCs and error states proliferate.
NT2 / Configured / Alberto / Configured subscription need to be refined in [event-notifications] and then adjust this document based on it.
NT3 / Filter / Express filter in JSON should be documented.
NT4 / Security / When a list of requirements for secure transport is provided via a Configured Subscription, this list must be met via Netconf transport. Specifics still are needed for draft on the "how".
NT5 / Compatibility / Along with rfc5277bis, this draft to obsolete 5277 (same as EN5)
NT6 / Steam,
Compatibility / Stream discovery. Adopted mechanism in 5277-bis and include backwards compatibility support.
Notif-restconf
Issue / Tags / Subteam / Issue / Next stepRT1 / Layering,
Stream / Integration specifics for Restconf capability discovery on different types of Streams
RT2 / Layering / In what way to we position "Event notifications" model in this document vs. current solution in Restconf.
RT3 / Security / Do we include 3rd party signaled subscriptions within models that need to be supported generically, or for a particular type of transport.
RT4 / Document / Need to add into document examples of 5277bis Event streams. Document only includes yang-push examples at this point.
RT5 / Transport / Doesn't make sense to use Restconf for Configured subscriptions. HTTP will be used.
RT6 / Encoding / We need to define encodings of rfc5277bis notifications for both Restconf and HTTP.
RT7 / Transport / HTTP native option doesn't currently use SSE. But we should evaluate moving to that as possible. It will make development integration easier and more consistent.