On 5/26/15, 8:40 PM, "Joel M. Halpern" <[email protected]> wrote:
>We discussed saving and re-exposing lower priority operations when >higher priority ones were removed. The working group decided that was a >bad idea, as it has a tendency to produce unintended consequences. Right, which is why I wrote that writing higher-priority value could wipeout lower-priority values, not simply shadow them. >Also, all direct over-writes among I2RS operations are considered >errors. They will need to produce notifications of these errors. And >then the higher priority one is applied as a means of producing >deterministic results, not because it is reliably right. I didn't mention notifications, but I think what you write is consistent with my proposal. >Also, if an I2RS client has read permission on I2RS data, it reads the >current value. No matter what priority the value was set using. There is the difference between config and op-state. I didn't mention op-state but I agree with your statement. >So I would be really unhappy with trying to model this as an overlay per >priority. It seems to produce even more complexity, more unexpected >results, and does not help us. To me it seems easier with more predictable results. That said, multiple overlays could be characterized as just an implementation detail, as it doesn't impact an I2RS Client's interactions with an I2RS Agent. >If I2RS data can be modeled as a single datastore with read-through to >the underlying operational state, and no possibility of performing a >commit then it can probably be made to work. Right, the overlay model gives us this. We seem to agree, only I'm not calling it a "datastore" for reasons described in my previous message. Thanks, Kent _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
