> On 19 Dec 2016, at 13:48, Juergen Schoenwaelder > <[email protected]> wrote: > > On Mon, Dec 19, 2016 at 11:37:57AM +0100, Ladislav Lhotka wrote: >> >> I am not proposing to ban candidate or something but IMO it needn't be part >> of the base NETCONF (or whatever protocol) spec. >> > > Lets recall that candidate is a _capability_. Nobody is required to > implement it.
Yes, this is what I wrote. My point is that this capability could/should be moved out of the NETCONF spec to a separate document. The latter can then be modified without affecting the former. > >> 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. >> > > The problem is caused by allowing users with inconsistent access > rights to both use candidate. So you get what you asked for. But I Well, as soon as you let clients manage their private data (user accounts, routing instances etc.) you get these "inconsistent" access rights automatically. > assume you can still do <discard-changes> and recover. ..., or find somebody with superuser privileges to perform the commit, but it is clumsy either way. Automated solutions are likely to break. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
