Joe: <chair hat off> This requirement that implementations provide "last write" and the ability to "ephemeral" wins (by setting a configuration flag) is a good addition.
I hope others will comment on this point. Sue -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Joe Clarke Sent: Tuesday, April 05, 2016 2:40 PM To: [email protected] Subject: [i2rs] Comments on last-write-wins (strawman) I wanted to follow up to my comments from the meeting and to the strawman I-D. The example shown in the meeting where ephemeral config overlays the running config in a single pane of glass makes a lot of sense. However, what happens when the next write isn't from another I2RS Client, but instead a "normal" NETCONF client? In that case, the last-write-wins rule takes effect, and the pane of glass holding the ephemeral config "shatters" leaving the running config as the derived state. I realize this is the default, but I definitely see use cases where I would not want the running config to win if it's the last write. As such, I'd like it to be mandatory that implementations include both the last-write-wins and the ephemeral wins options. What I see in the default case is that I may change the running config, which triggers an update to the I2RS Client holding the current ephemeral config, that Client then re-makes its change to overlay running, and now I have state churn that I may not want. Joe _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
