Hi All, I started this thread for a discussion on the Intended Status of the Revised DS Draft. I think the discussion on technical issues of the DS concept can be discussed on one maillist.
I call the new thread "Generic DS concept". Cheers, Mehmet -----Original Message----- From: netmod [mailto:[email protected]] On Behalf Of Ladislav Lhotka Sent: Wednesday, January 11, 2017 4:37 PM To: Robert Wilton <[email protected]> Cc: Netconf <[email protected]>; NetMod WG <[email protected]> Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits > 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
