[Netconf] Access control [was: ew draft-ietf-netconf-partial-lock-08.txt goes to AD

[Balazs Lengyel <balazs.lengyel at ericsson.com>]

Hello Randy,
Some other assumptions that might impact this issue:
- Do we have separate/differing access rights for running and candidate? (I hope not.)
- Your question stated somewhat differently: Do we have access control at edit-config/commit or 
both?
- for commit is the access control allowing the commit operation or the modification of the 
relevant data

We will run into some other interesting issues with access control
- how do you use validate (even for your own little area), if you don't have access rights to 
the full config? If validation can take into account areas that are non-readable for the user, 
that may lead to information leaks.
- can you lock the datastore if you are not allowed to read/write parts of it?

But all these are access control issues NOT partial-locking related.

Balazs

Randy Presuhn wrote:
> 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
>
> _______________________________________________
> Netconf mailing list
> Netconf at ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

--
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320                  email: Balazs.Lengyel at ericsson.com