Hi, all I had a chance to take a deeper look at this -02 version - not the other parts, but only the YANG model related to the data-source configuration, which I believe is the section 5.3.1 and Appendix A.1 in the current draft. Following are some contributor thoughts:
* I like the idea that we only define a very general list now and leave
the parameters specific to each data source to be extended in future, while I
am not convinced that the update-policy choice defined here is proper. My
intuition is that for reactive mode, the alto server waits data feed without
needing to poll. It could receive data as soon as it changes, but periodic
collection could also be another mode. I question whether a Boolean type of
reactive leaf is sufficient, and what if a false value is configured here? I
would rather use an empty type.
* I would like the update-policy choice to be defined outside
data-source list (but not very strong feeling), it is not the property of
data-source itself, but how the alto server get data from data-source.
That said, my suggested data-source tree diagram is following:
...
+--rw data-source* [source-id]
| +--rw source-id string
| +--rw source-type identityref
| +--rw (source-params)?
+--rw data-update-policy* [source-id]
| +--rw source-id -> ../../data-source/source-id
| +--rw (update-policy)?
| +--:(reactive)
| | +--rw (reactive-mode)?
| | +--:(on-change)
| | | +--rw on-change empty
| | +--:(period)
| | +--rw feed-interval uint32
| +--:(proactive)
| +--rw poll-interval uint32
...
* Regarding the Appendix part, it seems to me that some parameters are
still missing. The following tree diagram for a yang-datastore source example
could be for the authors' reference:
module: example-ietf-alto-data-source
augment /alto:alto-server/alto:data-source/alto:source-params:
+--:(yang-datastore)
+--rw source-server
+--rw name? inet:domain-name
+--rw datastore identityref
+--rw target-paths* [name]
| +--rw name string
| +---u yp:selection-filter-types
+--rw protocol* identityref
+--rw restconf
| +---u rcc:restconf-client-app-grouping
+--rw netconf
+---u ncc:netconf-client-app-grouping
The difference between *conf-client-app-grouping and
*conf-client-listen-stack-grouping is that the former also supports initiating
connections to servers proactively, which I believe is the more common case.
All related YANG modules are attached.
Best Regards,
Qiufang
example-ietf-alto-data-source.yang
Description: example-ietf-alto-data-source.yang
[email protected]
Description: [email protected]
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
