Subject: [Netconf] concurrent access to candidate

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 27 Jul 2011 11:04:30 -0400

Hi,

I'd like to clarify the options for concurrent access to candidate. Consider the following scenario:

1. An administrator works in candidate on implementing a major reconfiguration. This may take several hours, so the admin may not be to finish it in one session. So he applies a part of the changes and ends the session (releasing the lock on candidate).

2. A low-profile user opens a session and wants to make minor change, e.g. change his password. His attempt to lock the candidate is refused because of uncommited changes. So he executes "discard-changes", obtains the lock, applies his edit and performs a commit.

The only chance for the admini to avoid losing his work seems to be to keep the first session open with a lock on candidate, but this is against the requirement that the locks be short-lived. Or am I missing something?

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 27 Jul 2011 08:25:33 -0700

On 07/27/2011 08:04 AM, Ladislav Lhotka wrote:
> The only chance for the admini to avoid losing his work seems to be to keep the first session open with a lock on candidate, but this is against the requirement that the locks be short-lived. Or am I missing something

Why would the 2nd session even bother with discard-changes?
Most users tend to ignore locking because CLI ignores locking.
SNMP never had any locking.  (But just because 2 technologies are horribly
broken doesn't mean NETCONF should be just as broken. ;-)

The global candidate in NETCONF is seriously flawed.
Explicit global locking is not the best way to solve the multiple-writers problem.
This is certainly not the way source code control systems work.

Private candidates, which utilize mandatory-to-use implicit partial locking
is a much more robust solution.  It would also solve the commit-deadlock
problem which Wes has described many times.  There would no way a private
candidate could contain edits which could not be committed due to access control.

(I'm thinking of writing a draft, but private candidates require that
the global candidate is removed, which would make a server non-compliant.
An optional capability is not so straight-forward.)

> Lada

Andy

> --
> Ladislav Lhotka, CESNET
> PGP Key ID: E74E8C0C
>
>
>
>
>
>
>
> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 27 Jul 2011 13:27:38 -0400

> Most users tend to ignore locking because CLI ignores locking.

OK, but then we can end up with a candidate that nobody (except superuser) can commit, if our admin doesn't have write access to the low-profile user's password.
 
> candidate could contain edits which could not be committed due to access control.

I have been also thinking about representing pending changes to candidate as a list of patches. Then each patch can keep specific access rights depending on the user that performed it. Commit would then mean applying all these patches to running (atomically).
A reply to <get-config> asking for candidate could also be constructed at any time.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 27 Jul 2011 13:43:20 -0400 (EDT)

Andy Bierman <[email-masked]> wrote:
> > 1. An administrator works in candidate on implementing a major
> > reconfiguration. This may take several hours, so the admin may not be to
> > finish it in one session. So he applies a part of the changes and ends the
> > session (releasing the lock on candidate).
> >
> > 2. A low-profile user opens a session and wants to make minor change,
> > e.g. change his password. His attempt to lock the candidate is refused
> > because of uncommited changes. So he executes "discard-changes", obtains the
> > lock, applies his edit and performs a commit.
> >
> > The only chance for the admini to avoid losing his work seems to be to keep
> > the first session open with a lock on candidate, but this is against the
> > requirement that the locks be short-lived. Or am I missing something
> 

This is not the point.  The solution we come up with must work also
for the corner cases.

This said, I agree with your statement that the global / shared
candidate has its problems...  IMO, this is one of them.  If you work
with the shared candidate you have to be prepared for things like
this.  The alternative - that <discard-changes> requires access to the
things that will be modified - is worse. 

/martin