Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure

[Andy Bierman <[e-mail]>]

On Tue, Jul 12, 2016 at 12:07 PM, Juergen Schoenwaelder <
[e-mail]> wrote:

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

It only requires duplication if you insist on modeling opstate objects.
IMO an RPC + notification approach is far superior.
In this approach I only need to identify the intended config object
and retrieve (or be notified) of the applied-state transition.



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


We have read-only foo-state because we have only been standardizing
monitoring data for the last 30 years.  I completely agree that if the
state depends
on the config in order for an instance to exist, then co-locate the config
and
state and share the node naming.


But modeling admin-state and oper-state with the same object is not a
requirement.
Being able to determine if the intended config is applied yet is a
requirement.
This can be done with protocol operations so it is 100% data model neutral.




>
> /js
>

Andy


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