The following updated text was agreed:
- Complexity is shifted to Provider/Server controller - which has the best control of its own database evolution (preventing sequence/correlation mismatches).
- Stream types to support partitioning of information - useful e.g. to more specialized clients.
- Current solution cover UCs that do not benefit from top down provisioning of stream types - likewise for context provisioning: stream is in fact bounded to a TAPI context. The Provider can build different contexts to provide different representations of same (portion or slice of) underlying managed network.
- Malcolm Betts so far is the Provider/Server controller which builds contexts (and streams). For future phase the configuration by the Client Controller.
- A temporary stream can be dedicated to a testing activity - this could be a UC where some form of top down provisioning of dedicated context/stream type is desirable. Context here may be a subset of the network view, functional to test execution.
- Karthik Sethuraman is it possible to define a stream for a given TAPI subtree? Nigel Davis the idea is more generic, i.e. not necessarily depending on how YANG is eventually structured.
- Andrea Mazzini streaming should provide an organized and optimized stream of log entries/events, i.e. including state change plus its time stamp, hence appropriate history is preserved. This should save effort to Client controller, because today it must manage both notifications and GETs, which provide two partial/incomplete views to be reassembled. Stream data is always the same, for both synchronous and asynchronous operations. In other words, you do not need a special strategy for resync. Note the "missed deletion event/log" case: absence of the deleted item in the stream.
- Nigel Davis testing of streaming feature shall help to identify the advantages of the solution. E.g. verify that the compaction process is more efficient if performed on Provider/Server controller side.