Maybe I am missing something, but in terms of intended effect, I thought
it was pretty clear, with one degree of freedom that folks were arguing
about, how the interaction was understood by I2RS.
Given a device with an existing configuration, and a set of models
accessible by I2RS, what I2RS clients do is applied to the underlying
device, and is accessible at least by asking the I2RS agent what its
state is.
The ambiguity is what happens if someone comes in with CLI later.
Can they see the effect of I2RS? The group wanted it to be visible.
But it must not be confused with the actual config. Which may make it
hard to do.
If a CLI change affects something that has been modified by I2RS, what
happens? The easy part is that the config gets changed. The question
is what effect this has on the box. There are three chocies.
1) The CLI change takes effect, and the I2RS agent handles this with its
clients just the way it would if a higher priority client had overridden
the effect.
2) The CLI change simply does not take effect, and the operator is given
whatever warnings or notifications the system wants.
3) There is a priority for CLI, and it is compared with the I2RS
priority to choose between 1 and 2.
Choice 3 is what the I2RS group said it wanted. If that can be shown to
be non-meaningful, or too complicated, the group can revisit the question.
Yours,
Joel
On 12/2/14, 1:41 PM, Jeffrey Haas wrote:
On Mon, Dec 01, 2014 at 05:15:08PM +0000, Fedyk, Don wrote:
From: Martin Bjorklund [mailto:[email protected]]
Another way of stating this is that NETCONF commit semantics don't matter if
I2RS defines a new ephemeral datastore. (Modulo interactions with the config
datastore).
/martin
[Don] I agree. We need to define semantics for the datastore and predictable
results for the writable running state or active configuration. It seems to me
if there is priorities and overlap with various datastores there should be
blocking or overriding of ephemeral data too.
Interactions with things outside of the ephemeral config has been the
difficult thing for this discussion all along. While I'm happy that people
seem to be thinking harder about the protocol details, I'm not sure I've
heard anything convincing that we know what that means yet.
(Although I do find the edata comment from Andy for Restconf to be
promising...)
-- Jeff
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
