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. > > 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 the foo-state convention comes from the fact that 99% of the NM standards have been read-only until now. It is often desirable to index the monitoring tables differently than the configuration, even for opstate values. The data structures for counters may mirror the hardware, which may not be how the service configuration is indexed. The premise all those years (still valid today) is that standard monitoring makes it easier for application developers to write monitoring applications. Configuration was left to the proprietary CLI. It would be a mistake to lose standard monitoring unless and until the standard configuration was finished and implemented. This would be an unintended side effect of moving all monitoring under the configuration subtree for a feature. 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 > > 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
