Thx for the quick thoughts Rob. I2RS has defined that a 'set' would fail within the dynamic DS but they didn't really consider/specify that a 'set' to the dynamic DS could actually fail due to the existence of something in the conventional DSes. I suppose a custom DS (like the i2rs ephemeral) can in theory define whatever behavior they want but it may be odd that something written to the dynamic DS fails when there isn't something higher prio in the dynamic DS itself.
But someone can sort that out if they ever propose a model that is supported both in a dynamic DS and in a conventional DS (assuming we don't want to propose guidelines for that behavior in the revised DS draft). Rgds, Jason From: Robert Wilton [mailto:[email protected]] Sent: Tuesday, July 18, 2017 23:11 To: Sterne, Jason (Nokia - CA/Ottawa) <[email protected]>; [email protected] Subject: Re: [netmod] revised-datastores-03: duplicate list entry from conventional + dynamic Hi Jason, Some thoughts inline ... On 18/07/2017 22:46, Sterne, Jason (Nokia - CA/Ottawa) wrote: Hi all, The discussions about dynamic datastores in I2RS today made me wonder about a scenario: What if a data model is supported in both conventional datastores and in a dynamic datastore (as well as being readable from the operational datastore), and the same list entry (e.g. interface abc, but with some different parms in the dynamic entry vs the config entry) has been created in both the running and the dynamic DS. Only one of them can appear when reading the operational DS. Yes. I presume that it is up to the specification document of the dynamic DS to define the collision resolution between dynamic & conventional. Yes. But based on the revised DS draft I believe it would be necessary for the system to keep/store both copies of 'interface abc' so that a <get-data> with source=dynamic would return the dynamic version of interface abc while a <get-config> (or <get-data>) with source=running would return the conventional version of interface abc. Do I have that correct ? Definitely yes for running. For dynamic, it would depend on the definition of the specific dynamic datastore, but likely yes. I think that also implies that removing one of the copies could cause the 're-installation' of the other (down to the app layer). This would also depend on the definition of the specific dynamic datastore. Most likely, if the dynamic entry is removed, then the conventional configured value should be re-instated. However, I don't think that the reverse is necessarily true. E.g. in the dynamic datastore is I2RS then the initial config event would have failed if it was lower priority that conventional. This concept of storing multiple copies and re-installation is something I2RS wants to avoid. This is perhaps more related to multiple I2RS clients rather than between I2RS and the conventional datastores. But since they have declared that their scope only includes the use of their models in the dynamic (ephemeral) DS, they won't have that behavior. Rgds, Jason Thanks, Rob _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
