Hi,
On 11/01/2017 13:05, Ladislav Lhotka wrote:
On 11 Jan 2017, at 13:53, Martin Bjorklund <[email protected]> wrote:
Ladislav Lhotka <[email protected]> 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.
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?
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.
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
[email protected]
https://www.ietf.org/mailman/listinfo/netconf
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
