Subject: [Netconf] partial locking for candidate and startup?

From: Andy Bierman <[email-masked]>
Date: Sat, 01 Aug 2009 09:57:23 -0700

Hi,

Are there any plans to extend the partial locking
feature to the candidate and startup databases?

The WG has only addressed the 'SQL database model'
(write directly to the persistent database).

However, there are many networking devices
which use the :candidate or :startup capabilities.
If so, the partial locking feature is not applicable.

It is possible that partial locking for candidate
and startup would require too many changes to the protocol.
I am just wondering if this decision has already been made or not.

Andy

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Sun, 2 Aug 2009 23:01:50 +0200

I anm not sure if we made that decision explicitly.
But I do know that we as a result of discussions/concerns/issues, we came to
this text (as currently in revision 09, which is in IESG review):

2.1.1.  Usage Scenarios

   In the following we describe a few scenarios for partial locking.
   Partial locking is primarily useful towards the running
   configuration.  However it can be used to lock parts of a candidate
   datastore as well.  While scenarios using the running datastore are
   seen as the most important, as an example a scenario involving the
   candidate datastore is also presented.  Besides the three described
   here, there are many other usage scenarios possible.

Bert
  ----- Original Message ----- 
  From: Andy Bierman 
  To: NETCONF 
  Sent: Saturday, August 01, 2009 6:57 PM
  Subject: [Netconf] partial locking for candidate and startup?

  Hi,

  Andy
  _______________________________________________
  Netconf mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/netconf

------------------------------------------------------------------------------

  No virus found in this incoming message.
  Checked by AVG - www.avg.com 
  Version: 8.5.392 / Virus Database: 270.13.41/2277 - Release Date: 08/02/09 05:56:00

---

From: Andy Bierman <[email-masked]>
Date: Sun, 02 Aug 2009 14:22:13 -0700

>    here, there are many other usage scenarios possible.

The use case in 2.1.1.3 is a mystery to me.

I don't really see the point of locking my little
section of the candidate scratchpad, then manually coordinating
with all the other users (by email or SMS?)
"is it OK to do a commit now?".

If even one user doesn't get the memo,
and writes to the candidate ignoring all locks,
then the edit-config might succeed.
This can taint the commit -- either it will
fail, or maybe a hacker will get somebody
else to issue <commit> for some injected data under some other
user's credentials.

Partial locking does not work for candidate.

Andy

>     *From:* Andy Bierman <mailto:[email-masked]>
>     *To:* NETCONF <mailto:[email-masked]>
>     *Sent:* Saturday, August 01, 2009 6:57 PM
>     *Subject:* [Netconf] partial locking for candidate and startup?
> 
>     Hi,
> 
>     [email-masked] <mailto:[email-masked]>
>     ------------------------------------------------------------------------
> 
> 
>     Checked by AVG - www.avg.com <http://www.avg.com>

---

From: WashamFan <[email-masked]>
Date: Wed, 05 Aug 2009 14:08:34 +0800

HI,

>  "is it OK to do a commit now?".

How to do coordination is not clear in current text, but might be clear
in some body's mind.

>  else to issue <commit> for some injected data under some other

partial locking does not introduce this kind of vulnerability. it exists when
no locking used.

>  Partial locking does not work for candidate.
partial locking on candidate MIGHT work for somebody.

washam

---

From: Andy Bierman <[email-masked]>
Date: Wed, 05 Aug 2009 01:22:47 -0700

> How to do coordination is not clear in current text, but might be clear

A locking scheme that is voluntary may seem useful
to your mind, but not mine.

> partial locking does not introduce this kind of vulnerability. it exists when

no, it exists when partial-locking is used because
there is no global lock in effect.  A user which is
either unaware of the voluntary cooperative lock,
or is purposely trying to add config data to an
unlocked portion of the candidate, will succeed.

Depending on the access control model (if any),
this extra data that will be committed by a different
user may be OK or it may not let the commit finish.

Global locks are not voluntary.
The candidate config is global.
Locking part of the candidate is just like not using any
locks for all the unlocked parts.

Andy

---

From: WashamFan <[email-masked]>
Date: Wed, 05 Aug 2009 17:26:12 +0800

Hi,
 
>  locks for all the unlocked parts.

I totally agreed with what you said. But what I meant was if you don't
use lock (regardless of glocal or partial locks) at all, you face
this vulnerability, either. 

The point is if you consider this as a threat, please use global lock,
otherwise, you can use partial locks or no lock at all. 

Locks (regardless of global or partial locks) can not resolve all problems.
they aim to coordinate the at-the-time writes to locked objects. If you
think potential interruption to the whole config, grab a global lock, otherwise
a partial lock or no lock is OK.

We may on the same side.

washam

---

From: Phil Shafer <[email-masked]>
Date: Sat, 8 Aug 2009 10:40:26 -0400

>feature to the candidate and startup databases?

The opposite.  I've asked that explicit language
be added to the partial lock draft saying that
it is not compatible with :candidate, since partial
locking with full commits is a non-starter.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sat, 08 Aug 2009 08:19:16 -0700

> locking with full commits is a non-starter.

oh, sorry -- it was a trick question.
I agree that it is impossible to make the candidate
and startup databases work with partial-locking,
and remain compatible with the existing protocol operations.

I agree that the partial-lock draft needs to state
that it only applies to :writable-running, and only
if :startup is not concurrently supported.

Andy

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Sat, 08 Aug 2009 17:50:36 +0200

Phil and Andy, speaking as a document shepherd for the parial lock doc,
pls check the current revision of the doc. I do not think that it
is stated as strongly as you suggest below. Yet I believe you did not
object to the current text, neither during WG, nor during IETF Last Calls.

I just want to make sure we do not have text that would be objectionable
to some of our main contributers. I prefer not to have to open the complete
debate again.

It is on IESG agenda for coming thursday. I'd like it to pass by that date.

Bert

---

From: Andy Bierman <[email-masked]>
Date: Sun, 09 Aug 2009 09:36:28 -0700

> It is on IESG agenda for coming thursday. I'd like it to pass by that date.

I agree with Phil that it is harmful to interoperability
to even suggest that partial locking works on the candidate config.

I have no problem with limiting the scope of :partial-lock to
the 1 use-case where it is most needed.

Only high volume 'provisioning' applications really need partial
locking at all.  Only those platforms (or the very small platforms)
are likely to choose the 'SQL-like' database option and
just support :writable-running.

My concern (and perhaps Phil's concern) is well-founded.
We have seen over and over in the NETCONF work that a sloppy
sentence written 4 years ago can turn into all kinds of
implementation requirements that were never intended
in the first place.  Now there will be normative
text that piles on a new capability on top
of 2 old ones, in a manner that clearly does not work.

We have a global candidate config in NETCONF
and I prefer that it stay that way.  I don't want
any standard text anywhere that even suggests
that the candidate database tracks separate
change-sets per session, and commits them per-session.
For candidate, there is no partial-lock, partial-commit, or
partial-discard-changes, and it should stay that way.
Except, now there will be a partial-lock.

I object to the text in 2.6.1 and 2.6.3.
I cannot implement :partial-lock because of these additional
requirements that do not actually work.
Nobody is going to take out :candidate and :startup to support
this new capability.

I cannot allow partial locking on either candidate or startup,
so I cannot conform to the standard, even though I could
implement the only relevant portion of the document that works.

I do not think any agent implementation can support these requirements
and still support the RFC 4741 protocol operations in a robust
and pilot-error-resistant manner.

In case I am not clear enough, Bert, I strongly object
to the publication of this document in its current form.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 10 Aug 2009 15:18:12 +0200 (CEST)

Hi,

> locking with full commits is a non-starter.

For the candidate, it has been said before that partial-locking does
no more harm to the full commit model of the candidate than a
candidate with no locks what so ever (which is supported by 4741).

For startup, I think it makes sense to remove partial-lock, since we
have clarified in 4741bis that startup cannot be modified with
edit-config.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Mon, 10 Aug 2009 09:41:43 -0400

>candidate with no locks what so ever (which is supported by 4741).

For :writable-running, partial locking completely interfers with
the standard global locking, preventing even the most mundane
"archive the configuration" application from completing successfully.

For candidate, the entire purpose is to provide a simple transaction
mechanism.  Partial locks block the normal function of that mechanism,
preventing the use of locks, and putting us back in the "well I
hope I didn't just break the entire network" world.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Aug 2009 08:40:42 -0700

> candidate with no locks what so ever (which is supported by 4741).

I would spin it the other way...

Using partial-lock on candidate is as useful
as not using any locks at all.

The fact there there is exactly one corner-case (path=/)
that actually works is not impressive either.

Andy