On Tue, Jul 12, 2016 at 11:36:03AM -0700, Andy Bierman wrote:
> Yes there is value in modeling conventions in general.
> I am trying to understand the value of this specific convention.
> 
> If I have an RPC that asks for applied state, then it doesn't really matter
> how the config and state is organized.  There is only overlap in the objects
> if the data model is designed that way.
> 
> Whether or not an edit is applied yet is a property of the implementation,
> not the data model.

The current /foo and /foo-state approach requires some amount of
duplication. If the trees contain some nested lists of lists, you have
to at least replicate all the key leafs in the schema definition. For
a small model, this is not a bit deal; for more complex models, this
becomes complex and there are possible sources of errors. If it is
possible to simply data models, this may be a long-term win.

The reason why we have the /foo and /foo-state convention is, I
believe, the design of the NETCONF <get/> operation, which assumes
state and config can be represented together in a single tree. And we
have carried this further into YANG (e.g., the way contexts are
constructed for xpath expressions). In hindsight, I am not sure the
consequences of the <get/> design were that well thought through - but
I am not complaining, at that time we did not have YANG nor did we
have experience with bigger data models written in YANG. Is it worth
fixing it? This is a tough question and I understand that people have
different opinions and also different views on where we are on the
lifecycle of this technology. The challenge, as always, is to evolve a
technology along with its usage and upcoming new requirements. If the
evolution is too fast, you risk fragmentation since people will then
run many different versions. If evolution is too slow or stops
entirely, you pave the way for complete replacements of the
technology.

I think it is worth to step back for a moment and to think about where
we like to be in 5 or 10 years from now when we discuss architectural
questions.

/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/>

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to