Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes: > 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...
I thought the idea was (as the examples in 7895bis show) to have one module-set that is shared in schemas for both config datastores and <operational>. But then deviations cannot be used to differentiate between those schemas because deviations are specified per module-set. Lada > >> 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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
