On Fri, Oct 09, 2015 at 09:55:19PM +0000, Alexander Clemm (alex) wrote: > > The only item in the topology that is read-only concerns the > "server-provided" flag, but this concerns a separate issue that was > also discussed (I am not sure if this is what you are referring to). > It is analogous to the other discussion concerning distinguishing > configuration that has been intended, versus one that is in effect > etc . This concerns the issue that some topologies are populated by > the server whereas some topologies can be populated by client > applications.
Yes, this is what the concern is about. > We have had discussions in the past whether to "split this up", > having a (rw) branch to populate "intended" topologies and a (ro) > branch for topologies "in effect". This is the normal way to do this in YANG. And this goes back to what was driving us for years, namely to clearly separate config from state. This module makes this distinction a runtime property controlled by a data model specific mechanism. None of the generic tools out there will be able to understand this. > We decided against it for various reasons - every piece of > information would essentially be duplicated inside the model (this > is not your normal config vs oper data distinction, but would > essentially reflect a limitation of the framework), leading to > unnecessary additional complexity in the model (every augmentation > has to be conducted in two places), more complex validation rules, > etc. I do not understand why this is not a normal config vs oper data distinction. Please explain. I do not understand how this leads to more complex validation rules. Please explain. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
