On Tue, Jul 12, 2016 at 12:07 PM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> 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: +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
