Finally the NMDA datastores draft has reached WGLC, and I have been assigned as YD reviewer; quite an honor ;-) Because of the pretty fundamental importance of this document, I performed what I consider myself a pretty thorough review. Since this work has been going on for a very long time and with high intensity at times, I have not even tried to keep up to date with all the discussions. So in order not to resurrect all the beaten zombies that this spec has seen, I decided to let the document shepherd and principal author Martin Björklund review my review. The end result of which is that I withdraw every one of my comments and proclaim review result Ready. For full transparency (and to show that I wasn't lazy after all), I have enclosed my initial review findings below. Note that I now feel that they are either discussed enough already, addressed in a different document (e.g. YANG library), or misunderstandings/proposals on my part that do not necessarily merit further discussion or clarification. Finally I will add that no blackmail or bribery ;-) was involved in me reaching this conclusion; merely a good discussion. /jan Topic #1: Loss of operational stringency According to RFC 6020 tradition, config false data returned from operations MUST adhere to the constraints declared in the YANG modules; max-elements, must statements, unique keys, etc. This is obviously a high standard to live up to for server implementors. With NMDA, the situation reverses so that operations will return data from where no semantic guarantees apply. This moves the burden of managing flux and inconsistency from the servers to the clients. Now each client has to be able to deal with potentially duplicate keys, violated constraints and generally that any YANG model semantic guarantee is a mere recommendation. Personally I find this rather shocking. One of the core values in NETCONF/YANG has always been that it sides with the "operator" or "client" view of the world. Decades ago we had SNMP (Simple ...) -- which in practice meant simple to *implement*, not simple to use. NC/Y is supposed to be the other way around. Hard to implement, but easy to use. If we feel strict adherence to the YANG declaration is a bar too high for operational data, maybe we could find some middle ground? Just giving up and saying that anything anywhere may be violated anytime is to make it too easy for implementors and too hard for clients, IMHO. If I'm beating on a dead horse here, I apologize ;-) I just want to ensure that if this is what we want, it should be an informed decision. Topic #2: Actions live in NMDA says actions are always invoked in context of the data store. In many cases I agree this makes good sense. But there are a couple of catches here. The first catch relates to timing. As the server is not obliged to make an element committed in immediately available in , a client that creates a bit of configuration and is interested to execute an action on it will not know when to fire the action. Should it poll for the object creation? Keep retrying? I sense the creation of Heisenbugs and interop issues. The second catch relates to structure translation between and . If the configuration committed to by the client has no direct counterpart in and , there is nothing to invoke the action on. Say I used a templating feature in to define a bit of configuration, and now I want to execute a check-sync action on that piece of config to see that the config has propagated properly. There is no context to invoke the action on in . Similarly, for actions that update (e.g. config wizards), executing in would make sense. Maybe an ability to specify the context datastore in the rpc would be enough to fix this. Or better perhaps, the target datastore should be formally declared by the action/rpc? Such a declaration would solve another issue that exists today. A client needs to parse English to know if an action changes . Any configuration data cached by the client would need to be invalidated iff so. With a formal mechanism to declare which datastores are (not) affected, clients could be a lot more efficient. This is a real issue. Topic #3: Datastore specific deviations How would I express a deviation that applies to one datastore but not another? Say, for example, that I have a deviate not-implemented on an object in but I support it in . Topic #4: NMDA compliance declaration How would a client know that a server works according to NMDA principles? I suppose the intent is that there is no need to know because things are "backwards compatible", and that for a given server the answer may vary depending on which data model we're talking about. But as discussed in topic #1, #2, #3 above (and more below), significant semantic differences are introduced by NMDA. As client implementor, I would want to know what to expect from a server. Topic #5: Origin of unset values When the operational view is constructed, the draft describes situations where the operational value may be taken in some cases from or:intended and in other from or:learned. While it would be valuable for clients to understand what the precedence rule is, this may be a bit too complex to declare formally, since it is quite possible that the mechanics of which value shows up isn't always simple and may depend on other leaf values. In the example with a DHCP learned address trumping an intended address, it could be that the DHCP server specifies only an IPv6 address. In which case the device policy might be to override the IPv4 address in intended with no value. In this situation, there is no way for the server to communicate why there is no IPv4 address (it was or:learned), since the origin attribute cannot live on a non-existent XML element. So the origin mechanism does not work well for optional elements. Topic #6: Datastore and origin identity trees Why are there two trees with identities, one for datastores and one with origins? Most values seems to be the same, with the origins being a superset of the datastores. By organizing them into a single tree with all the datastores as one branch of the origins tree, we could get something simpler. moduel ietf-origin { identity origin; identity unknown { base origin; } identity system { base origin; } identity learned { base origin; } identity default { base origin; } identity datastore { base origin; } identity conventional { base datastore; } identity running { base conventional; } identity candidate { base conventional; } identity startup { base conventional; } identity intended { base conventional; } identity dynamic { base datastore; } identity operational { base datastore; } /* * Type definitions */ typedef origin-ref { type identityref { base origin; } } typedef datastore-ref { type identityref { base datastore; } } Topic #7: Editorial Below are a few details about the wording: On pages 3 and 4, it is said that "These datastores share a common datastore schema" and """datastore schema: The combined set of schema nodes for all modules supported by a particular datastore, taking into consideration any deviations and enabled features for that datastore.""" If we have a device that support macros/templates/services in , which expands into concrete configuration in , I don't suppose the macro/template/service instances would be part of ? If so, I guess the schemas are not exactly the same? Maybe we can say that is a subset of the schemas (plus all the config false data)? p15: Maybe we could point out that learned values etc MUST NOT update / to make this entirely clear. p24: Juergen Schoenwaelder's funding is mentioned, but not his participation p27: what's ? p28: ds-ephemeral and or-ephemeral are not great names. Will be referred to as ds:ds-ephemeral and or:or-ephemeral. Would prefer ds:ephemeral and or:ephemeral. /jan