On Tue, Jan 10, 2017 at 8:16 AM, Juergen Schoenwaelder < j.schoenwael...@jacobs-university.de> wrote:
> On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote: > > On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder < > > j.schoenwael...@jacobs-university.de> wrote: > > > > > On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: > > > > > > > > I think itt is not realistic to say that datastores are optional. > > > > > > > > e.g. <enabled> leaf: If there is a standard way to enable/disable > config > > > > then individual "enabled" leafs are redundant. However XPath > (must/when) > > > > has no way to describe if the subtree is enabled (which is a > > > show-stopper) > > > > > > I may not understand what you are saying. From what I know, there are > > > implementations that allow to 'comment out' nodes and subtrees and > > > that work with clients in a backwards compatible way. > > > > > > > <foo-config> vs <foo-oper>. If the applied or operational datastore > is > > > > assumed, > > > > then there is no need to model the redundant config-as-operstate. > > > > If this is left out of the model, then the datastore becomes > mandatory. > > > > If it is left in the model, the datasore becomes redundant. > > > > > > > > The basic premise that these datastores are optional is flawed. > > > > One cannot design a YANG module assuming the datastores are present > > > > if they are in fact optional. > > > > > > The claim that all datastores are mandatory is equally flawed. > > > > > > > > correct -- nobody is saying that. > > Well, I originally commented on the statement that intened would be > required and adding complexity - it does not. > > > The reason this is different is that the YANG objects are impacted. > > Candidate vs. running has no impact whatsoever on the set of > > YANG modules. The protocol is not self-selecting some objects > > and making other objects invisible. > > Yes. And the same is true for intended as long as an implementation > does not support templates or inactive configuration objects. > > > But if I want to model <foo-state>, I will soon have to decide > > to use <foo-state> and allow all protocols to read it or > > model get-state(foo) and require a different module for each > > protocol. > > If you do /foo and /foo-state, things will just work with or without > an operational state datastore. If you have only /foo, then an > operational state datastore may come in handy if you have to support > config and state with different lifetimes. > Will they really work without /foo-state? How will I write XPath must/when/leafref statements for foo-state if it doesn't exist? (BTW, why do I need foo-state in both applied and operational datastores? This part is not clear) If the solution is to introduce an XPath function like operational-value(/top/speed) then this is both complicated and mandatory (YANG designers need the same XPath function set on every server) > /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
