On Thu, May 10, 2018 at 05:07:23PM +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote: > Hi all, > > In the NMDA approach we're trying to combine config & state into the same > common tree structure. i.e. For a given list, model a single list that > contains both config & state, vs separate lists for each of config & state. >
NMDA uses different datastores, only configured leafs appear in the configuration datastores. > But what happens when the valid value space for config vs state is different > ? For example -> what if an implementation has internally created > interfaces with names that start with '_internal_' and doesn't allow > configuration of those interfaces ? These interfaces will appear in <operational> but not in <running> and <intended>. They will also have a proper origin tag. > If there were separate config vs state lists then the config list may have a > pattern associated with the key that disallows names that start with > '_internal_'. Oh, you are concerned about your implementation not allowing _internal_ for a configured interface? Well, in that case, I think the server needs to reject the creation of such an interface. > To keep the spirit of NMDA it would be a shame to split into separate config > & state lists for this case. Any recommendations ? > > 1) make the 'pattern' for the key be a superset (i.e. allow _internal_) and > then just reject config requests for _internal_ interfaces (e.g. at commit > time) ? This seems the way to go. The loopback interface is often system created and it is commonly called 'lo' or something like this. I assume a server will reject a request to create an interface named 'lo' which is a vlan interface on top of an ethernet interface. Looking at RFC 7223, I found that the description of /interfaces/interface/name talks quite a bit about the fact that a system may put restrictions on the names that are accepted. > 2) make the 'pattern' more strict to match config, and then return _internal_ > interfaces for state queries (that in theory break the pattern for the key) ? I think the type of key leafs should allow all possible key values. > 3) other suggestions ? With the new YANG library, I think one could have a deviation that narrows down the type for the configuration datastore schemas. But then people do not like deviations... > Another example could be an integer key that has a larger range for state > than it does for config (i.e. IDs >1000 are for internal entries only, not > configurable). Perhaps concrete text in the description statement is the simplest solution. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
