[Catching up on list traffic after being sick for a bit.] On Wed, Nov 04, 2015 at 07:53:28PM -0500, Russ White wrote: > First -- in terms of granularity -- I don't think anyone should be modifying > parts of a RIB entry. Rather, each "object" should be treated as an "object" > in full. This is something that needs to be addressed in the models -- what > is essential, and what is accidental.
I think we chatted briefly about this. While I think we agree in principle that this is a desired behavior, the methods to implement this are what is leading to the discordance: - If we have a yang schema representing a RIB, nothing in netconf/restconf prohibits one party with sufficient permissions from tampering with a subset of nodes associated with a given RIB entry. The issue is fundamentally we're allowing different parties to scribble on top of pieces of configuration. This is a configuration based mechanism. - If we only interact with the RIB via something like a RPC call defined in yang, then the properties of not interfering with another entry can be enforced by the implementation of that RPC. This is more of an API based mechanism. The logic implementing the RPC provides the enforcement. An API based mechanism addresses the issue, but the question basically comes down to how to expose the remainder of the associated state for the RIB in such an implementation. Do we expose operational state? If so, we can have a config=false representation of that state. How do we expose the provisioned state? Do we require the user to issue a series of RPCs to get the state? It would be very convenient if it were present as a config=true set of nodes, but this is the problem we're avoiding. What we'd end up with is potentially something similar to what the OpenConfig group wants: state that is provisioned, but distinct from the operational state of the system. In this example, it'd be effectively a second piece of operational state. I'm thinking more and more that a significant portion of our problem spaces come down to some form of the above discussion. I2RS priority is rather painful to create and enforce when your interface to provision it is config=true nodes in an ephemeral datastore. It's a bit clearer when it is provisioned via RPC instead. -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
