I thought this had been discussed previously but couldn’t find the email.
IMO option 1) makes more sense, the key range should be a superset of config and oper since the model applies to both. Don’t know if there’s any mechanism which allows for different range per datastore. Regards, Reshad. From: netmod <netmod-boun...@ietf.org> on behalf of "Sterne, Jason (Nokia - CA/Ottawa)" <jason.ste...@nokia.com> Date: Thursday, May 10, 2018 at 1:07 PM To: "netmod@ietf.org" <netmod@ietf.org> Subject: [netmod] NMDA - different valid keys for config vs state 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
