Subject: [Netconf] NACM issue?

From: Andy Bierman <[email-masked]>
Date: Mon, 02 Jan 2012 10:32:17 -0800

Hi,

I am running into some yuma implementation issues that may have some impact on NACM.

A server cannot really preserve the individual edits on candidate by multiple writers,
when applying the commit.  The safe thing to do is determine which nodes are really
changing in the running config at commit time. (e.g., consider multiple edits on the same node).
Since the server has to derive edit operations based on the actual differences between
candidate and running, the NACM rules can be affected.

The granularity for NACM access is probably too fine.
E.g, session A has full rights to /foo/* and creates a /foo list entry in the candidate.
Session B has only full access to the /foo/knob1 leaf, and it creates /foo/leaf1
in the candidate.  At this point /foo does not exist in the running config.
Depending on the NACM rules and candidate contents, perhaps no session has enough
rights for a commit to succeed at this point. (We assume A can still commit here ;-)

This /foo/leaf1 write access will not fail in NACM when the <edit-config> is done
because the implicit (or explicit) edit operation on /foo is 'none'.
However, a commit attempt by session B must fail because it cannot create the /foo node.

There are many corner cases one could construct where individual edits to the
candidate will be OK for a given group, but not the end result commit request.

I don't think the NACM draft needs to change, but I suspect multi-writer candidate
commits will not be implemented correctly (like yuma right now ;-)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 02 Jan 2012 21:43:03 +0100 (CET)

Hi,

Andy Bierman <[email-masked]> wrote:
> changing in the running config at commit time.

This is also described in the draft:

 3.2.6.  <commit> Operation

   The server MUST determine the exact nodes in the running
   configuration datastore which are actually different, and only check
   "create", "update", and "delete" access permissions for this set of
   nodes, which could be empty.

> candidate will be OK for a given group, but not the end result commit request.

Yes, this has been discussed before.

> commits will not be implemented correctly (like yuma right now ;-)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 02 Jan 2012 13:44:39 -0800

On 01/02/2012 12:43 PM, Martin Bjorklund wrote:
> Hi,
>
> Andy Bierman<[email-masked]>  wrote:
>   3.2.6.<commit>  Operation
>> This /foo/leaf1 write access will not fail in NACM when the<edit-config>  is
>> done

OK -- I guess administrators will be careful with NACM rules.
Complete write access (CUD) vs. no write access at all will always work
as expected.

Did we cover this case, or is it implied:

   list mylist {
       key idx;
       leaf idx { type int32; }
       leaf delnode {
          when "../leaf1 = 5";
          type string;
       }
        leaf leaf1 { type int32; }
   }

   Start:

<mylist>
<idx>1</idx>
<delnode>ok to delete me?</delnode>
<leaf1>5</leaf1>
</mylist>

User A has write access to /mylist/leaf1, but not /mylist/delnode.
User A changes /mylist/leaf1 from '5' to '42' in the candidate config, which works.
User A attempts a commit, which fails with 'access-denied' error for deleting /mylist/delnode.

Should only an actual <commit> attempt will produce this error, or should the <validate>
function return the same error?

Does <validate> mean "this config is OK" or "this config is OK and you can
perform all the requested edits"? IMO, it has to be the former because there
may be no target config specified (w/ inline <config>) to derive edit operations.

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 10 Jan 2012 06:32:01 -0800

>>>>> On Mon, 02 Jan 2012 10:32:17 -0800, Andy Bierman <[email-masked]> said:

AB> There are many corner cases one could construct where individual edits
AB> to the candidate will be OK for a given group, but not the end result
AB> commit request.

I think you've all heard my "global operations are dangerous" speech too
many times, so I won't repeat it :-P  One of these days I'll have the
hours to write some drafts to fix my problems.

But, one other thing to note: race conditions exist as well and NACM
can't be implemented properly without locking.  Specifically, even if
only a single user edits the candidate config and NACM checks it and
ensures it can be copied to running, if the copy operation and NACM both
pull from the actual candidate config (as opposed to a temporary copy of
it), then there is a race.

  T+0 NACM checks and verifies
  T+2 copy-config places the copy into running

Obviously, the problem is:

  T+1 user B edits /foo/bar

-- 
Wes Hardaker
SPARTA, Inc.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Jan 2012 07:51:37 -0800

On 01/10/2012 06:32 AM, Wes Hardaker wrote:
>>>>>> On Mon, 02 Jan 2012 10:32:17 -0800, Andy Bierman<[email-masked]>  said:
>

Good - write a draft

>    T+1 user B edits /foo/bar

I'm not following this example.
The server does not check candidate for NACM rules, just running.
Some internal caching of ACM details insures that the rules in affect
at the start of the message are used throughout the entire message.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 10 Jan 2012 09:18:25 -0800

Hi -

> From: "Andy Bierman" <[email-masked]>
> To: "Wes Hardaker" <[email-masked]>
> Cc: "NETCONF" <[email-masked]>
> Sent: Tuesday, January 10, 2012 7:51 AM
> Subject: Re: [Netconf] NACM issue?
>

This problem isn't a question of where the NACM rules live.  The heart
of the problem is the candidate / running / copy-config way of doing things
in the presence of multiple users with potentially differing permissions.
In the example Wes gives, changes made by user B, which have not been
checked against user *A*'s permissions, get copied into the running
configuration as a side-effect of copy-config.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Jan 2012 09:48:53 -0800

On 01/10/2012 09:18 AM, Randy Presuhn wrote:
> Hi -
>
>> From: "Andy Bierman"<[email-masked]>
>> To: "Wes Hardaker"<[email-masked]>
>> Cc: "NETCONF"<[email-masked]>

It is an implementation detail, but a server can figure out what actually
changed in a commit or copy-config.  The session attempting the <commit>
or 'external' <copy-config> operation has to be authorized to perform
all the edits (derived from the XML-diff), even for deletion of false when-stmt
nodes that happen to turn false as a side effect of other edits.

The candidate can deadlock, where no 1 user has enough rights to
commit all the edits, and thus require some user to invoke <discard-changes>
to clear the deadlock.

Direct writes to running cannot cause such a deadlock, since a full validation
is required for each edit.

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 10 Jan 2012 16:48:46 -0800

Hi -

> To: "Randy Presuhn" <[email-masked]>
> Sent: Tuesday, January 10, 2012 9:48 AM
...
> commit all the edits, and thus require some user to invoke <discard-changes>
...

Sounds like a recipe for a DoS attack, in which a relatively
unprivileged user could prevent another user from getting his/her
work done.  Trivial example:  A and B have rights to modify disjoint
subsets of information.  Either can block the other indefinitely.

Randy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Jan 2012 11:18:11 +0100

>   nodes, which could be empty.

The cardinal question is what "different" means here. Is it

(a) diff of candidate versus running, or
(b) set of changes that the user made to candidate?

I assume it must be (a), because candidate is copied to running at commit. But then the following nasty conflict may easily happen:

User A works on candidate and in the mean time somebody changes running in a place to which A has no write permission. If user A were now allowed to commit the candidate, the changes to running would be reverted, which is not possible. So the commit must be denied even though all changes A really made to candidate are fine. 

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

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 11 Jan 2012 11:24:13 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> >> A server cannot really preserve the individual edits on candidate by
> >> multiple
> >> writers,
> >> when applying the commit.  The safe thing to do is determine which
> >> nodes are
> >> really
> I assume it must be (a), because candidate is copied to running at
> commit.

Yes.  I suppose this could be further clarified as:

   The server MUST determine the exact nodes in the running
   configuration datastore which are actually different compared with
   the candidate datastore, and check "create", "update", and "delete"
   access permissions for this set of nodes, which could be empty.

> But then the following nasty conflict may easily happen:
> 
> User A works on candidate and in the mean time somebody changes
> running in a place to which A has no write permission. If user A were
> now allowed to commit the candidate, the changes to running would be
> reverted, which is not possible. So the commit must be denied even
> though all changes A really made to candidate are fine.

Yes, but only if :writable-running and :candidate is advertised at the
same time, and I think we have agreed that this is a Bad Idea.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Jan 2012 11:27:08 +0100

> subsets of information.  Either can block the other indefinitely.

This issue has been discussed some six months ago, with no resolution:
http://www.ietf.org/mail-archive/web/netconf/current/msg07063.html

I think a really robust solution would have to use per user candidate which is actually regarded as a patchset - a sequence of edits.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Jan 2012 11:28:53 +0100

> same time, and I think we have agreed that this is a Bad Idea.

Hmm, perhaps running can be changed outside NETCONF (e.g. via CLI). Then you get the same problem.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Jan 2012 03:13:22 -0800

On 01/11/2012 02:27 AM, Ladislav Lhotka wrote:
>>> To: "Randy Presuhn"<[email-masked]>
>>> commit all the edits, and thus require some user to invoke<discard-changes>
>>> to clear the deadlock.
>> ...
>>

If the client uses global locking, there is no problem.
I am finding that locking is being used in application development.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Jan 2012 12:31:22 +0100

> I am finding that locking is being used in application development.

I my scenario from the said old thread, the global lock would have to be really looong-term which is not a good option either.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 11 Jan 2012 09:27:36 -0800

>>>>> On Tue, 10 Jan 2012 07:51:37 -0800, Andy Bierman <[email-masked]> said:

>> hours to write some drafts to fix my problems.

AB> Good - write a draft

I'd love to, but I don't have work funding to do it and my personal life
is currently overburdened with volunteering to multiple public service
organizations.

>> T+1 user B edits /foo/bar

AB> I'm not following this example.
AB> The server does not check candidate for NACM rules, just running.
AB> Some internal caching of ACM details insures that the rules in affect
AB> at the start of the message are used throughout the entire message.

Well, it's really checking the changes right to ensure that the
modification imposed by the copying was legal or not.  There are
multiple ways of implementing it.

- You could copy first, then check, then revert (which would be bad for
  the fraction of a second it was in place).
- You could check first and then copy, but then you need to make sure
  that nothing changes between the point it was checked and the point it
  was copied (in *either* storage place).  That's really the example I
  was trying to state.
- ...  I'm sure there are others ...

The problem is we don't give implementation advice, but when it comes to
security features like ACM modules it's rather critical you get it right
or bad things happen.  But we don't document all the ways you could
implement it poorly (with some good reason: it'd be an exhaustive list).
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 11 Jan 2012 09:32:45 -0800

>>>>> On Wed, 11 Jan 2012 11:27:08 +0100, Ladislav Lhotka <[email-masked]> said:

LL> This issue has been discussed some six months ago, with no resolution:
LL> http://www.ietf.org/mail-archive/web/netconf/current/msg07063.html

Actually, we discussed it two San Diego's ago (my new favorite unit of
time measurement) I think and it was decided you had to use locks.  And
that it was ok that the protocol didn't really support simultaneous
edits by multiple people very well, as that wasn't an important goal as
it's not used in 95% of deployments.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 11 Jan 2012 09:36:09 -0800

>>>>> On Wed, 11 Jan 2012 11:24:13 +0100 (CET), Martin Bjorklund <[email-masked]> said:

MB> Yes, but only if :writable-running and :candidate is advertised at the
MB> same time, and I think we have agreed that this is a Bad Idea.

Or :writable-running and copy from URL.

Or :candidate and copy from URL with two people editing 2 different
copies and trying to copy them in from different locations.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Jan 2012 10:07:54 -0800

On 01/11/2012 09:36 AM, Wes Hardaker wrote:
>>>>>> On Wed, 11 Jan 2012 11:24:13 +0100 (CET), Martin Bjorklund<[email-masked]>  said:
>

RFC 6241, sec 8.3.1, para 3:

    The candidate configuration can be shared among multiple sessions.
    Unless a client has specific information that the candidate
    configuration is not shared, it MUST assume that other sessions are
    able to modify the candidate configuration at the same time.  It is
    therefore prudent for a client to lock the candidate configuration
    before modifying it.

I admit the RFC does not scream USE LOCKS! as much as it should,
but this problem existed with multiple CLI sessions way before
NETCONF came around, and operators don't seem to care.

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 11 Jan 2012 10:13:57 -0800

>>>>> On Wed, 11 Jan 2012 10:07:54 -0800, Andy Bierman <[email-masked]> said:

AB> The candidate configuration can be shared among multiple sessions.
AB> Unless a client has specific information that the candidate
AB> configuration is not shared, it MUST assume that other sessions are
AB> able to modify the candidate configuration at the same time.  It is
AB> therefore prudent for a client to lock the candidate configuration
AB> before modifying it.

AB> I admit the RFC does not scream USE LOCKS! as much as it should,
AB> but this problem existed with multiple CLI sessions way before
AB> NETCONF came around, and operators don't seem to care.

It's not just that, though.  Both candidate and running must be locked
to prevent problems.  Only locking one won't fully protect you.

-- 
Wes Hardaker
SPARTA, Inc.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 11 Jan 2012 10:19:43 -0800

> copies and trying to copy them in from different locations.

Also from RFC 6241:

4.5.  Pipelining

    NETCONF <rpc> requests MUST be processed serially by the managed
    device.  Additional <rpc> requests MAY be sent before previous ones
    have been completed.  The managed device MUST send responses only in
    the order the requests were received.

Your comments seem to assume that edits from different <rpc> requests
can be applied concurrently in the server.  (Maybe some servers, but
yuma is not that clever, so <rpc> N is completed before <rpc> N+1 is started).

IMO, the text above implies that internal edits will be serialized, not just <rpc>
processing, so even multi-threaded servers need to preserve the order of edits.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 11 Jan 2012 19:28:32 +0100

> therefore prudent for a client to lock the candidate configuration

In fact, a client shouldn't release the lock before *commiting*, which 
can be much more annoying.

> NETCONF came around, and operators don't seem to care.

The fine-grained permissions of NACM make this problem worse.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 11 Jan 2012 12:16:38 -0800

>>>>> On Wed, 11 Jan 2012 10:19:43 -0800, Andy Bierman <[email-masked]> said:

AB> 4.5.  Pipelining

AB> NETCONF <rpc> requests MUST be processed serially by the managed
AB> device.  Additional <rpc> requests MAY be sent before previous ones
AB> have been completed.  The managed device MUST send responses only in
AB> the order the requests were received.

AB> Your comments seem to assume that edits from different <rpc>
AB> requests can be applied concurrently in the server.  (Maybe some
AB> servers, but yuma is not that clever, so <rpc> N is completed before
AB> <rpc> N+1 is started).

I had forgotten about that clause, so thanks for reminding me of it.

My visions are sometimes more grandiose toward the future, when every
machine has multiple cores, multiple threads and multiple servers
because the configuration space is simply that big.

We learned in the SNMP world that forced pipe-lining was a bad thing for
data retrieval requests (IE, GETs) because it blocked multiple managers
querying the agent at the same time when some queries were long in
executing.

One of the most annoying things of SNMP, and now with netconf, was that
there wasn't a way to state that two different data sets are independent
and are allowed to be acted on simultaneously.  For config, it's
probably not as much of a problem since it really should be a copy and
should be instantaneous.  Oh wait, unless you need to restart process X
because the config changed.  Oh wait, and you need to unload a kernel
module because the config changed, etc.  As configuration grows (which
it never seems to stop doing), the whole system will continue to explode
into huge numbers of things that can be twiddled.  Which means without
paralyzing some stuff, the single configuration engine will become the
bottleneck.  But you're right, the above rule does prohibit some of the
issues I'm worrying about and my other grandiose problems won't be seen
for a while yet :-)
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Jan 2012 09:23:46 -0800

On 01/11/2012 12:16 PM, Wes Hardaker wrote:
>>>>>> On Wed, 11 Jan 2012 10:19:43 -0800, Andy Bierman<[email-masked]>  said:
>
> AB>  4.5.  Pipelining
>
> AB>  NETCONF<rpc>  requests MUST be processed serially by the managed
> AB>  device.  Additional<rpc>  requests MAY be sent before previous ones
> AB>  Your comments seem to assume that edits from different<rpc>
> AB>  servers, but yuma is not that clever, so<rpc>  N is completed before

That doesn't mean the monolithic CLI management model will remain in place.
I think the trend towards 'private candidates' or even virtual servers
will solve this problem.

> querying the agent at the same time when some queries were long in

I agree this is a useful feature, not specific to SNMP.

> issues I'm worrying about and my other grandiose problems won't be seen

I agree that the NETCONF/YANG configuration model is still incomplete.
But the ad-hoc nature of NM features is the fault of the vendors,
not the standards.  If a product requires several manual steps, like restart
a process, reboot the device, set 5 knobs in some exact order, then
the inherent complexity of the overall system will be huge (like what we
see now with routers ;-)

Developers (and their managers) don't seem to understand that their random acts
of 'schedule beating' design choices have a huge impact on the usability of the software.

The reason NM is still in the Stone Ages has nothing to do with SNMP vs. NETCONF vs. CLI,
or ASN.1/BER vs. XML .vs. JSON, and everything to do with the ad-hoc, poorly documented 'recipes'
needed to cook up any particular networking feature. (There's some hope REST will solve this.)

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 12 Jan 2012 13:51:35 -0500

>querying the agent at the same time when some queries were long in

IIRC nothing in NETCONF prevents multiple simultaneous queries.
Simultaneous locks/changes, yes, not queries.

In the CLI world, we learned if you don't apply changes in distinct
change-sets (ala commit), then simple operations like "backup/restore"
become obnoxiously difficult (since you can't know if what you
archived was a complete configuration).

We also learned that forcing operations to be performed in certain
orders makes simple operations (like changing a filter) into complex
ones (since it might require the filter to be built multiple times).
Using a candidate config increases the chances of accurate config
changes while decreasing the amount of work required to make them.

I think these lessons carry over directly into the APIs, where one
wants to make a particular operation (add a service) and wants to
know the service is added correctly, works correctly, and can be
undone if it does not.  Accuracy and simplicity win over multiple
writers.

>and are allowed to be acted on simultaneously.

If the data sets are truly independent, consider distinct datastores.

One area we haven't explored is "learned pseudo configuration",
where one considered "configuration data" is taken to be permanent,
but "learned data" is some of the same knobs, but learned from
services that don't wish them to be permanent.

Consider subscriber management as the best example.  When the
subscriber is present, some external app wants to tell us how their
port should be configured, but they don't want it to be real
configuration data.  In JUNOS, we do this via a second datastore
(called the dynamic database).  It's never saved/restored, and one
only looks at it when debugging the subscriber management app.

Food for thought....

Thanks,
 Phil (who is only lurking here these days)

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 12 Jan 2012 21:50:51 +0100 (CET)

> IIRC nothing in NETCONF prevents multiple simultaneous queries.

Correct.

> Simultaneous locks/changes, yes, not queries.

The standard doesn't prevent simultaneous changes either, only
simultaneous global locks (obviously...).

With partial locks, you can have multiple (protected) simultaneous
writers as well.

(Yes I know partial locks only works with running, and some sort of
private candidates are needed...)

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 13 Jan 2012 08:25:05 +0100

> only looks at it when debugging the subscriber management app.

The lack of support to handle this kind of operational (config) state
is well known. Are we getting ready to finally do something about it?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 13 Jan 2012 09:24:30 -0800

>>>>> On Thu, 12 Jan 2012 13:51:35 -0500, Phil Shafer <[email-masked]> said:

PS> If the data sets are truly independent, consider distinct datastores.

Yes, but netconf doesn't really push that concept well.  You'd need
separate ports (or at least ssh service names) for each datastore for
each back-end independent config.  That's not ideal.

Netconf has re-implemented the windows registry when operators really
just want a set of editable /etc files wrapped with 'git push' into it.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 13 Jan 2012 09:25:47 -0800

>>>>> On Fri, 13 Jan 2012 09:24:30 -0800, Wes Hardaker <[email-masked]> said:

WH> Netconf has re-implemented the windows registry when operators really
WH> just want a set of editable /etc files wrapped with 'git push' into it.

Ok, first off: sorry for the negativity.  Don't get me wrong: I think
netconf has come a very long way and good things have been done.  I
don't want to say the entire system isn't useful, and the above text
does sound that way.  It is a good system, but IMHO, still incomplete
from where we need it to get to.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 13 Jan 2012 21:39:46 +0100

Dne 13.1.2012 18:24, Wes Hardaker napsal(a):
>>>>>> On Thu, 12 Jan 2012 13:51:35 -0500, Phil Shafer<[email-masked]>  said:
>

Yes, I think we can learn a thing or two from the modern DVCS systems. A 
'pull' strategy might also be considered, where a superuser decides what 
changes prepared by somebody else will be accepted and when.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Phil Shafer <[email-masked]>
Date: Fri, 13 Jan 2012 15:02:50 -0500

>just want a set of editable /etc files wrapped with 'git push' into it.

That's not what I hear from operators, but maybe our customer overlap
is zero.  Viewing config as a set of /etc files in a source repository
would be a nightmare IMHO.

FWIW, the most common comment I get is that as long as they have
to use Expect scripts to configure non-NETCONF routers, using fancier
methods with our gear isn't a sufficient win.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 13 Jan 2012 21:54:02 +0100

> would be a nightmare IMHO.

Instead of files in a directory we can think about subtrees in a repository.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Jan 2012 16:02:56 -0800

> is well known. Are we getting ready to finally do something about it?

I am finally addressing this issue in yuma with a YANG extension.
This comes up from time to time in user requests.
IMO, there are several use cases for restricting user create, update, and/or
delete operations, and the following YANG extension covers all of them (I hope).

(Shameless plug -- this will be in the next release of yuma at the end of the month)

   extension user-write {
     description
       "Used within database configuration data definition
        statements to control user write access to the
        database object containing this statement.

        The 'permitted' argument is a list of operations
        that users are permitted to invoke for the specified node.
        These permissions will over-ride all NACM access control rules,
        even if NACM is disabled.

        This extension does not apply to descendant nodes!
        This extension has no effect if config-stmt is false!

        The following values are supported:

          * create : allow users to create instances of the object
          * update : allow users to modify instances of the object
          * delete : allow users to delete instances of the object

        To dis-allow all user access, provide an empty string
        for the 'permitted' parameter (user-write '';)

        To allow only create and delete user access, provide
        the string 'create delete' for the 'permitted' parameter.
        Use this for parameters that cannot be changed once they
        are set.

        Providing all 3 parameters has the same affect as not using
        this extension at all, but can be used anyway.

        leaf user-write {
          description 'equivalent YANG definition';
          type bits {
           bit create;
           bit update;
           bit delete;
         }
         default 'create update delete';
       }

     ";

     argument exceptions {
       yin-element true;
     }
   }

Examples:

    container interfaces {
       ncx:user-write update;   // only system can create & delete
       ...
    }

    leaf set-once {
        // cannot modify; instrumentation only supports delete and re-add
        ncx:user-write "create delete";
        ...
    }

    leaf uuid {
        // only system allowed to write this leaf
        ncx:user-write "";
        ...
    }

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Jan 2012 16:59:26 -0800

>> On Thu, Jan 12, 2012 at 01:51:35PM -0500, Phil Shafer wrote:
....
>>> only looks at it when debugging the subscriber management app.

Actually, the user-write extension addresses a different problem.
You can easily solve this problem now with a special RPC operation,
like 'set-subscriber-port'.  You can put the temp config in read-only
if needed.

It isn't really config if it is not meant to be saved.
That has been our definition for a long time, and it still seems valid.
To use config=true, there would need to be some new YANG mechanism to indicate
when to delete the data, and not to save it in NV-store.
(See old email logs for 'tconfig' transient-config email discussions for config=true
data that never gets NV-saved, and gets dropped across a reboot.  (I like to remind you
that I wanted 3 states for config-stmt way-back-when :-)

Andy

---

From: Carl Moberg <[email-masked]>
Date: Sat, 14 Jan 2012 09:24:49 +0100

> just want a set of editable /etc files wrapped with 'git push' into it.

 Ok, I'll bite. Yes, NETCONF has introduced the concept of a consistent
 interface and behavior for a set of managed objects that may or may not
 be implemented in a consistent manner. If that is re-implementing the Windows
 Registry then there are many things in the computer industry that are mere
 re-implementations of that.

 For the second half of the sentence; no they don't. They want a combination
 of a useful CLI (network-wide if possible) and comfortable scripting and
 programming environments (e.g. based on NETCONF and perhaps REST) with
 support for transactions. They also would like standard data models for
 core protocols. They also want to keep SNMP for traps and simple PM and
 FM functions.

Regards,
--
Carl Moberg, Tail-f Systems
mailto:[email-masked]
twitter: @cmoberg
http://www.tail-f.com/