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.
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 ? 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_'. 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) ? 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) ? 3) other suggestions ? 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). Rgds, Jason
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
