Subject: [lmap] merging /lmap and /lmap-state

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Nov 2016 19:29:20 +0100

Hi,

when I started to draft the first versions of the YANG data model some
2+ years ago, I started to follow the /foo and /foo-state approach
that separates the state tree from the config tree. This pattern
evolved out of the work on the ietf-interfaces YANG module and related
YANG data models. The technical reasons for the /foo and /foo-state
approach do not really apply to LMAP since we do not necessarily have
to support different lifecycles for config and state and we are not
provisioning config for hot-pluggable resources.

Since Spring this year, I have been working on a proposal for a
revised datastore model that, among other things, does not require
anymore to separate configuration data from state data. From what I
have heard, this revised datastore model (which introduces a separate
operational state datastore) seems to be well received by the NETMOD
and NETCONF working groups.

So I started to think about what does it take to merge the /lmap and
/lmap-state branches together. It turned out that the actual edits are
very straight forward. The whole data model gets about 5% shorter (we
save all the duplicated container and list definitions in the
/lmap-state branch) and I find the merged model significantely easier
to understand. The merged YANG model also is a bit closer to the
information model, in particular with the modeling of
capabilities. Hence, I propose to move forward with the merged trees
as this simplifies the model. I am attaching the two tree pyang -f
tree outputs so you can easily see the difference of the structures.

If there are any reasons against merging the trees, please raise them
now otherwise I will post -08 early next week with the merged tree.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>