> On 9 Jan 2017, at 19:37, Andy Bierman <[email protected]> wrote: > > > > On Mon, Jan 9, 2017 at 4:50 AM, Ladislav Lhotka <[email protected]> wrote: > > > On 9 Jan 2017, at 13:38, Lou Berger <[email protected]> wrote: > > > > > > > > On January 9, 2017 7:25:24 AM Ladislav Lhotka <[email protected]> wrote: > >> > >> The current document involves quite a lot of hand-waving, and that's why I > >> was also reluctant to accept it as a WG standard-track deliverable. > > > > > I do not agree with this hand-waving assessment. > What are the show-shoppers? > > I agree the draft is light on use-cases.
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? > 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. Lada > > > > IMO I think we should do and document the work and then, once the is > > general agreement, worry about number and publication status of documents. > > I agree, but we have to accept it will take some time. The problem I see is > that quite a few people already work with the solution. > > > The solutions I've seen were not very good, so they need a lot of work. > I expect that the operational datastore will be more widely implemented > than any of the others. Designing a <get> replacement is not that difficult. > > > > Lada > > Andy > > > > > > Lou > > > > > > -- > 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
