> On 19 Dec 2016, at 09:09, Jonathan Hansford <[email protected]> wrote: > >> -----Original Message----- >> From: netmod [mailto:[email protected]] On Behalf Of Ladislav >> Lhotka >> Sent: 14 December 2016 14:25 >> To: Andy Bierman <[email protected]>; Mehmet Ersue >> <[email protected]> >> Cc: NetMod WG Chairs <[email protected]>; NetConf WG Chairs >> <[email protected]>; NetMod WG <[email protected]>; Netconf >> <[email protected]> >> Subject: Re: [netmod] [Netconf] WG adoption poll draft-nmdsdt-netmod- >> revised-datastores-00 >> > : >> As for candidate, it is optional and we all know that it is quite > problematic if >> concurrent access of multiple clients is possible. Therefore, it would IMO > be a >> good riddance. > > For someone who is yet to see NETCONF and YANG used in anger, can you > explain why judicious use of candidate and lock is problematic with > concurrent access and why, as a consequence, it should be got rid of? One of
I am not proposing to ban candidate or something but IMO it needn't be part of the base NETCONF (or whatever protocol) spec. A typical problem of candidate combined with NACM is that user A edits item X and B edits Y in candidate. If B doesn't have write access to X and A to Y, then none of them is able to make a commit. Lada > the features of NETCONF that attracted us to it is its support for > transactioning, a feature which it would appear came from previous > experience with JUNOS. Is it current guidance that transactioning should not > be used? > > Jonathan > >> >> Lada > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
