Re: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes to AD andIETF Last Call

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

> From: "Balazs Lengyel" <balazs.lengyel at ericsson.com>
> To: "David B Harrington" <dbharrington at comcast.net>
> Cc: "'Ron Bonica'" <rbonica at juniper.net>; <netconf at ietf.org>
> Sent: Thursday, June 04, 2009 12:37 AM
> Subject: Re: [Netconf] New draft-ietf-netconf-partial-lock-08.txt goes to AD andIETF Last Call
>
> Hello,
> I have to repeat, that the conflict is NOT the result of partial-locking, it is between access 
> control and commit. So why should partial-lock be responsible for solving access control issues?
> 
> Unless the chairs and the AD agree with my reasoning, I propose to immediately remove 
> partial-lock for candidate and startup. While I stand by my earlier arguments, and disagree 
> with David, I want to settle this issue fast, and rather remove startup and candidate, then 
> keep on arguing.
> 
> However remember, that restricting partial-lock to running, will not make the access 
> control/commit conflict go away.

If one believes that access decisions are made during "commit" then
all these horrible things *will* happen, and it's broken, just as Balazs argues.

If access decisions are *not* made during "commit"  then the problem goes away.

The problem, if I recall an off-line discussion correctly, is the language in an
example in the netconf spec that indicates that access decisions are made
during the commit.  Other than that, I see no reason for access decisions to
be made during commit time in a single-candidate view of how things should
work.

Randy