Re: [i2rs] [[e-mail]: I-D Action: draft-haas-i2rs-ephemeral-state-reqs-00.txt]

[Kent Watsen <[e-mail]>]

On 5/26/15, 8:40 PM, "Joel M. Halpern" <[e-mail]> 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