On 11/01/2017 14:48, Ladislav Lhotka wrote:
On 11 Jan 2017, at 15:18, Robert Wilton <rwil...@cisco.com> wrote:
Hi,
On 11/01/2017 13:05, Ladislav Lhotka wrote:
On 11 Jan 2017, at 13:53, Martin Bjorklund <m...@tail-f.com> wrote:
Ladislav Lhotka <lho...@nic.cz> wrote:
<snip>
Show me a single YANG data node definition that's duplicate in my
concept above. But then maybe I didn't explain it properly.
The interface's "type" leaf. With the new operational-state
datastore, /interfaces/interface/type in operational-state and
/interfaces-state/interface/type are duplicate.
As I said, ietf-interfaces-state state would consist of augments containing extra state
nodes (i.e. those that are not in configuration). So "type" won't be there.
I think that this effectively just achieves the same thing that the "config:
true|false" statement indicates in a combined config/state tree.
Personally, I think that a file of augmentations is probably going to be harder
to read than having the config and state schema in one tree in one file.
Possibly we could also use schema mount. On the other hand, it doesn't enforce
the use of operational-state datastore. A simple device like a WiFi-controlled
electric socket could easily use just ietf-interfaces-config (and
ietf-ip-config), i.e. no state data.
Another example I am dealing with now is OpenWRT: with some effort, it would be
possible to translate our nice configuration data into UCI files without
touching the OpenWRT system itself. On the other hand, serving state data
according to our YANG modules is a non-starter.
Isn't the proper answer here to generate deviations to remove the state
leaves that won't be implemented.
The models may also be slightly more inconvenient to use because the state tree
leaves would presumably be in a different namespace from the configuration?
Yes, but I don't think it is a big problem - even for human readers.
I'm not sure. I think that you might end up with a variation of the
OpenConfig models, and based on experience I would say that those models
are hard to read if they haven't been compiled first to expand the
groupings and reveal the actual structure.
Rob
If you wanted this file level split then using submodules would allow for
separate config/state files but still be managed as a single combined module.
But it means you have to implement both.
Lada
Rob
Note also that you slightly misinterpreted my statement that you
cited:
I believe both the protocols and YANG can work with any set of
datastores [...]
I didn't say that there cannot be *modules* that are somehow designed
for a particular datastore model - I meant YANG the language.
Ok. Yes, you're right, but then we'd probably need some new statement
in each module that tells which meta-model the YANG module is written
for.
I would prefer to have it as state data, basically separate YANG libraries for
configuration datastores and operational-state.
Lada
/martin
Lada
/martin
Am I completely misguided here? If not, then I don't see where the new
modules refer to any particular datastore model. Yes, they do reflect
that there is configuration and state data, but we don't want to get
rid of this distinction, right?
Lada
/martin
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
Netconf mailing list
netc...@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
.
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
