> On 11 Jan 2017, at 16:18, Robert Wilton <[email protected]> wrote: > > > > On 11/01/2017 14:48, Ladislav Lhotka wrote: >>> On 11 Jan 2017, at 15:18, Robert Wilton <[email protected]> wrote: >>> >>> 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. >> 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.
This is of course possible but deviations are generally frowned upon, so why not use the modularity features for making it a little more flexible? I know some people will now say that without state data it is no proper network management but, speaking pragmatically, automated configuration would be a big boon by itself. > >> >>> 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. One thing that makes modules really hard to read are augments, and we already have them all over the place. It's a trade-off between readability and modularity. Lada > > 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/netconf >>>> . >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> >> >> >> >> . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
