Re: [netmod] Yangdoctors early review of draft-ietf-netmod-revised-datastores-09

[Juergen Schoenwaelder <[e-mail]>]

Jan,

thanks for sharing your review - an interesting read. Many of the
issues you have touched upon have kept us quite busy during 2017, both
on the mailing list and during the regular webex calls of the main
contributors. Thanks for actually sharing your notes.

/js

On Tue, Jan 09, 2018 at 07:43:31AM -0800, Jan Lindblad wrote:
> Reviewer: Jan Lindblad
> Review result: Ready
> 
> 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 <get>
> 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 <get> operations will return data from <operational> 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 <operational>
> 
> NMDA says actions are always invoked in context of the <operational> 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 <intended> immediately available in <operational>, 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 <running> and
> <intended>. If the configuration committed to <running> by the client has no
> direct counterpart in <intended> and <operational>, there is nothing to invoke
> the action on. Say I used a templating feature in <running> 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 <operational>.
> 
> Similarly, for actions that update <running> (e.g. config wizards), executing
> in <running> 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 <running>. 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
> <running> but I support it in <operational>.
> 
> 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 <running>, which
> expands into concrete configuration in <intended>, I don't suppose the
> macro/template/service instances would be part of <intended>? If so, I guess
> the schemas are not exactly the same? Maybe we can say that <intended> is a
> subset of the <running> schemas (plus all the config false data)?
> 
> p15: Maybe we could point out that learned values etc MUST NOT update
> <running>/<intended> to make this entirely clear.
> 
> p24: Juergen Schoenwaelder's funding is mentioned, but not his participation
> 
> p27: what's <get-data> ?
> 
> 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
> 
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>