On Mon, Jan 9, 2017 at 12:51 PM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Mon, Jan 09, 2017 at 09:18:46PM +0100, Ladislav Lhotka wrote:
> >
> > I am more concerned about use cases that are not known so far, and so I
> am against standardizing this (or any other) workflow as the only one
> supported by NETCONF/RESTCONF and YANG. I believe both the protocols and
> YANG can work with any set of datastores, but their choice depends on the
> use case at hand. Why should IoT developers be exposed to the
> running-intended-applied complexity, even if they are allowed to lump all
> three into one?
> >
>
> Please point me to the statement in the I-D that makes you believe an
> implementation is required to support all datastores.
>
> > > There are no standard mechanisms that cause <running> to be
> > > different from <intended>, so I would agree the intended datastore
> > > needs a lot more standards support before it is useful.
> > >
> >
> > The only difference seems to be the presence of templates but I don't
> know what they are.
> >
>
> The I-D says:
>
>                             |        // e.g., removal of 'inactive'
>                             |        // nodes, expansion of templates
>
> So it is not just templates. And yes, these are things several
> real-world implementations can do but where the IETF did not yet
> managed to standardize anything. The basic question is whether we want
> a model that is (a) capable to match real-world implementation and
> that allows for future standards of existing proprietary technology or
> (b) we go with what we have today (either chartered or published) and
> we keep revising the model as we move ahead.
>
>

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)

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


/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

Reply via email to