Subject: Re: [Netconf] Summary of the NETCONF WG Session in IETF 71 and Action Items

From: Balazs Lengyel <[email-masked]>
Date: Wed, 04 Jun 2008 18:01:31 +0200

Hello Wes,
(Catching up after being drowned by other work.)

What would you expect to appear in the partial-lock draft about potential pitfalls of partial 
locking?
In the last part of your mail you write:
 > A partial-lock is another form of a partial config and that was my only
 > point in the meeting.  It doesn't add new problems, it just compounds
 > the study case.

It already contains:

"The system ensures that configuration resources covered by the lock
    are not be modified by other NETCONF or non-NETCONF management
    operations such as SNMP and the CLI."

Would you like a chapter:
Modifications to existing operations containing:
Partial lock will prevent the execution of operations effecting the whole datastore e.g. 
commit, copy-config, delete-config if they would result in modifications to the locked area.

regards Balazs

Wes Hardaker wrote:
>>>>>> "ME" == Mehmet Ersue <Ersue> writes:
> 
> ME> => Wes Hardaker: 
> ME> Please post your questions on:
> ME> - what happens if you copy candidate to running 
> ME> while a partial lock is held? 
> 
> Here's a quick summary about partial vs global commands.  Locking is one
> type of command that has both a global (in the core netconf model) and
> partial (in the newly proposed partial locking draft).
> 
> Global commands are those that operate on entire configuration
> datastores at once.  EG, <copy-config>, <delete-config>, <lock>, ...  It
> affects the whole configuration datastore or it doesn't.  If, when
> authorization comes along, a netconf user don't have write access to the
> whole configuration store it's currently undefined as to what happens,
> though some obvious things are probably apparent (a copy-config by a
> user with restricted access shouldn't be allowed to change parts of a
> config being copied TO that they're not authorized to change).
> 
> Partial commands are those that operate on pieces of a configuration
> datastore.  Examples include <edit-config> and <partial-lock> (I don't
> remember the exact command name for that, unfortunately...  That may not
> be it).  In these types commands the user will or will not have the
> ability to execute the command based on what part of a datastore it's
> acting upon.  IE, a user will be prohibited from partically-locking a
> part of a datastore it doesn't have the authorization to lock.
> 
> 
> The trouble comes in when trying to mix these modes.  Consider the case
> where two different operators have different access rights to a
> particular configuration datastore (if you want an example where this is
> going to be required for new work, see
> draft-hardaker-dnsops-name-server-management-reqs-02.txt which documents
> management requirements for DNS management).  If you have two different
> users (say U1 and U2) that are responsible for separate pieces of the
> configuration datastore you can run into conflicts between them.  If,
> for example, U1 has the ability to edit only the routing information and
> U2 only has the ability to edit DNS service configuration then if
> they're both trying to configure their parts of the system at the same
> time then everything works just fine as long as they don't use any
> global commands.
> 
> EG, if they both partially lock their portions of "running", edit it,
> and then unlock they'll never see problems.
> 
> However, if they both partially lock the candidate config, edit it such
> that there are outstanding changes to both the routing configuration and
> the DNS service configuration then it's possible neither U1 nor U2 will
> have access rights to perform the copy-config to actually copy the
> changes made from the candidate to the running configuration.  U1 won't
> be able to since changes exist in the DNS configuration portion and he
> doesn't have write access to that portion of the running config, and
> vice-versa for U2 with respect to the routing configuration.
> 
> A partial-lock is another form of a partial config and that was my only
> point in the meeting.  It doesn't add new problems, it just compounds
> the study case.  EG, if U2 partially locks the DNS service configuration
> portion of running then it prevents U1 from performing a copy from
> candidate to running which blocks U1 from the edit path they wished to
> take.  The only choice is for U1 to do edits only on running (or wait
> for the partial-lock to be lifted which may be never if mal-intent is
> involved).
> 
> ME> - need a matrix that covers the various operations and their
> ME> interaction
> 
> That was just a comment that a "nice to have" piece of documentation
> would be a chart that displayed which commands had what affect on which
> pieces of the whole system.  As new pieces/operations/commands keep
> getting added to the system it gets more and more complex to study from
> any perspective, and most importantly, a security perspective.
> 
> 
> But to be clear I'm not misunderstood: I think partial-locking is a good
> thing, not a bad thing.  I actually think the system would be easier if
> it disallowed global commands altogether.  But that's another story for
> another day and will only likely caused me to get flamed off the mailing
> list ;-/

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 04 Jun 2008 18:01:31 +0200

Hello Wes,

It already contains:

regards Balazs