Hi,
On 09/01/2017 21:17, Andy Bierman wrote:
On Mon, Jan 9, 2017 at 12:51 PM, Juergen Schoenwaelder
<[email protected]
<mailto:[email protected]>> 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.
I agree that these datastores are not all really optional.
Current YANG models are structured assuming that there is no operational
state datastore. They could be used on devices that support an
operational state datastore, but there would likely be duplication of
some of the data because it is represented in two places.
But to design clean models with combined config and state, it is
necessary to assume support for both "running" and also "operational
state" datatstores. Such models could theoretically be used by devices
that don't support the operational state datastore, but key information
would be unavailable, so this doesn't feel like a pragmatic solution.
However, it would to straight forward to write tooling (i.e. a plugin to
pyang) that takes a YANG module designed assuming an operational state
datastore and generate the missing config false leaves so that the model
could also be used on devices that don't support an operational state
datastore.
This raises the question, or how do you know whether a model has been
designed assuming support for an operational state datastore? For me the
simplest solution appears to be to mark the models as YANG version 2.0.
I would also propose revising NETCONF and RESTCONF to version 2,
allowing the protocols to change to support an operational state
datastore in a clean way. E.g. if a device supports an operational
state datastore then it doesn't really make sense to continue to support
the existing NETCONF GET operation.
Thanks,
Rob
/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/
<http://www.jacobs-university.de/>>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
