Subject: Why Phil is right about <special-set> vs. <edit-config>

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Sep 2006 08:18:47 -0700

Hi,

First, I am not going to say we need to stop using <edit-config>.
I just going to point out a critical SNMP problem the XMLCONF design
team really wanted to fix -- but didn't.

The root problem in NE management today is the relative expense
and difficulty in adding new agent functionality into NE devices.

SNMP Set failed for 3 reasons:
 1) Casting high-level procedures as a "100 bits of peek/poke data"
    is an Unnatural Act that never had a chance of succeeding.
 2) One generic "edit" PDU that can contain an arbitrary mix
    of arbitrarily incomplete high-level operations (i.e. varbinds),
    dispensed like gumballs, across an arbitrary number of Set PDUs.
 3) In accordance with the Postel Principle, the agent needs to code
    for complex (legal) Set PDUs the manager should never ever use.

NETCONF has better error reporting then SNMP, but the complexity
of implementing <edit-config> in an optimal manner is non-trivial.

In contrast, none of the arbitrary mix-and-match "Gumball API" problems
exist with <special-set> RPCs.  The agent automation complexity is
dramatically lower than for <edit-config>.  Agent callback chains
can handle hard problems like resource reservation and rollback
much easier as well.

The <special-set> approach is much better for managers,
because an "object-oriented API" can easily be mapped to
services or classes, and the set of methods defined for them.

The "fly in the ointment" is the startup config file
(e.g., show running config).  This data-centric view
of the configuration state is heavily used, and not going
away any time soon.  The trick is finding the right mix
of heuristics, mappings, and special RPCs, so both views
of the NE device can be easily supported.

Andy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 14 Sep 2006 11:20:01 -0400

Hi,

I agree that <special-set> RPCs are needed to help reduce complexity
of SET functionality. 

I also think we need to understand how to standardize <set> and <get>
functionality for interoperability across vendors.

-- data versus functions --

I have commented in the past about the comparison of NM approaches to
programming languages.
SNMP uses the peek/poke approach of an assembly language, a 2nd
generation programming language.

The CLI is the equivalent of a 3rd generation language, such as
Fortran, Cobol, C, or Pascal. It is function-oriented. This is much
more "natural" for a human being to use, as it is task oriented. An
important feature of later functional languages is the concept of
variable scope. Functions may touch any data anywhere in the
application space, and this can cause bugs when one function's code
modifies a variable that another function expects to remain constant
(or at least not to change in a "volatile" manner). To constrain the
side-effects of modifying variables, langauges like C introduced the
concepts of function-scope (local variables) and file scope
(structures only modifiable by functions in the same file that defines
the structures).

Object-oriented, the fourth generation of langauges, takes it a step
further by having data that is specific to an object that is only
modifiable by the fucntions (methods) of the object. In this way, the
data definition is unknown except internally. Objects in an O-O
environment also are derivable from base classes, promoting
hierarchical reuse. 

I stopped following the evolution of programming languages at fourth
generation, but I think the fifth generation is the use of remote
procedure calls and the existence of "objects" callable across the
network. This requires the ability to build components that are
largely self-sufficient and have a "public" interface to manipulate
its private data (an extension of the data hiding from 3rdgen scope
and 4thgen "data hiding").

Why am I suddenly giving lessons in programming langauges? Because we
need to decide where on the continuum netconf should fit, and much of
that decision will have to do with the incompatibility of standard
data models and global functions such as the <get-config> RPC, and the
concepts of data hiding.

-- iteration and an object-oriented hierarchy --

I have programmed in C++ for years, working on a NMS application that
used object-oriented design for modeling the network. Each device
model had public methods and hidden data. One of the toughest problems
we ran into was "searching the network" for specific data, because it
required having a search routine for every object, and a search
routine that iterated through every object in the hierarchy. 

Of course, we could derive objects from a base class that has a search
method that could iterately call the search method for all derived
classes. Derivation is hard to work with, and an object hierarchy is
hard to get right in a manner that works for multiple "world-views";
how one models the hierarchy depends a lot on what you are trying to
achieve.

To do <get-config>, we will probably need to define a <get-config> RPC
for every object you plan to use to modularize the hierarchy (I assume
a capability might represent the definition of an object), and we will
a consistent varbind format to report the object's data, and roll the
data up into a complete picture of the configuration. And ideally, the
"varbind" format will not place any restrictions on
implementation-specific decisions of data modeling within the
"object".

Assuming the "objects" will exist in some type of hierarchy, it will
probably be necessary to define a mechanism for "rolling up" the data
through the hierarchy. For instance, calling the <get-config> for a
chassis might cause the chassis code to iterate through <get-config>
for each blade in the chassis, and combine these subordinate configs
with the chassis's own config information. And because you don't want
each blade's <get-config> trgggered by the chassis AND by a direct
iterative <get-config>, we will need to make some provision for
recognizing when a complete subtree has been queried by the
<get-config> command. Mayeb Xpath already solves this iteration
problem.

-- sets versus gets --

<special-set> RPCs are needed to help reduce complexity of SET
functionality. But what about <special-get> RPCs?

I suggest we consider a system that uses only <special-set> functions
for SET functionality, and uses both global <get-*> and <special-get>
RPCs. 

<special-sets> can make the functionality addressable in a
standardized manner, make modification of data "gumballs" predictable,
and make the details implementation-specific to a large degree
(support data hiding and proprietary schema pieces). I expect we will
want to standardize portions of a <set> data model into a standard
schema, and allow this to be supplemented with vendor-specific
parameters in one or more supplemental schemas.

The <get-*> and <special-get> operations should have a standard
reporting format to improve interoperability, and to promote the
development of standard data models for monitoring and cross-vendor
comparison capabiltities. Failure to impose some standards on the
format of the returned values leads to the problem faced today by
operators trying to use expect scripts to parse through inconsistent
and constantly changing proprietary CLI data models. XML will help,
but will fall short if each vendor uses different schemas for the same
functionality.

One area this WG has not discussed is how to do access control. This
has been pushed off as data-model-dependent. But if the interface to
functinoality will be functions rather than peek/poke, then access
control should probably be applied to each function, not to the
underlying gumballs of data that might get modified.

It is possible that two types of access control will be required -
read access might be best modeled as data-hierarchy-centric, while
write access might be best modeled as function-centric. Of course, if
we bundle data and functions into objects, and the hierarchy is at the
object level, then access control could be object-centric, and we
would avoid the overkill of per-variable access control.

P.s. it might be worthwhile looking at the <*-config> commands as
being an object as well, and the <get-config> and <edit-config>
commands are methods specific to managing the functionality of a
"running config" object. 

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Tuesday, September 12, 2006 11:19 AM
> To: Netconf (E-mail); Netconf Data Model Discussion
> Subject: Why Phil is right about <special-set> vs. <edit-config>
> 
> Hi,
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Sep 2006 18:29:26 -0700

> Hi,

Interesting comments.
One quick reply on access control:

I think we need a comprehensive tiered access control
model that works for any RPC on any data.  RPC invocation
has to be the basis of the model, or a device can't be properly
secured when vendor RPCs are used.

At a minimum, we need to:

1) check that the user is allowed to invoke the specific RPC method
2) if relevant, check that the data under <config> (or other data root elements)
    can be accessed by this user as requested (granularity TBD)
    - minimum granularity is at (read, write)
    - maximum NETCONF granularity is (create, delete, merge, replace)

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 18 Sep 2006 11:33:40 +0200

Hello,
One specific problem we have with access control:

It would be nice if we could check access control just based on the incoming RPC, the 
userID/group and his access control rights; without a need to know what is already in the 
datastore. However if I get a request like (in approximate netconf):

<edit-config operation=merge>
   <top>
     <interface-eth0>
       <adminstate>Up</adminstate>
     </interface-eth0>
   </top>
</edit-config>

and the user has read rights on all parts of the data model but write rights only on the 
adminstate but not on the interface level I have a problem.
Depending on the current content of the datastore <interface-eth0> might be
- a request to create the interface which must be denied
- a reference to an existing eth0 interface, so the request should be allowed.

Is there any easy solution for this?

Balazs

PS. Generally I believe <edit-config> with it's four operation possibilities is a complex 
thing to implement. In some cases it would be enough to allow only "null" as a default 
operation and only create/delete (and maybe replace) as subsequent operations. This would 
make life much easier for some nodes. Sadly merge is mandatory in the draft.

Andy Bierman wrote:
>> [email-masked] [email-masked]
>> [email-masked]
>>  
>>
>>
>>
>>> From: [email-masked] [mailto:[email-masked]] 
>>> On Behalf Of Andy Bierman

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Vincent Cridlig <[email-masked]>
Date: Mon, 18 Sep 2006 12:09:54 +0200

Hello,

I have the same problem.
We control access before calling MIB modules for executing the request. 
The reason is that we don't want each module to implement access 
control. This is too costly.
The second reason is that if several modules have to be called for the 
same request and one module decides that access should be denied, we 
have to rollback the other modules.

However, because of the merge operation and the default operation 
concept, sometimes only the MIB modules know what concretely must be 
done on the config.

What we did until know is to deny the operation when the context does 
not allow the access control process to decide.
And we specify as precisely as possible the requests on the manager side 
(using the operation attribute).

Regards,
Vincent

Balazs Lengyel a écrit :
> It would be nice if we could check access control just based on the 
> incoming RPC, the userID/group and his access control rights; without 
> a need to know what is already in the datastore. However if I get a 
> request like (in approximate netconf):
>
> and the user has read rights on all parts of the data model but write 
> rights only on the adminstate but not on the interface level I have a 
> problem.
> PS. Generally I believe <edit-config> with it's four operation 
> possibilities is a complex thing to implement. In some cases it would 
> be enough to allow only "null" as a default operation and only 
> create/delete (and maybe replace) as subsequent operations. This would

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Sep 2006 07:41:04 -0700

> have to rollback the other modules.

IMO, both of your approaches are flawed.
You have to check each child node against the target,
from the root to every leaf node.  This is no different
than checking every parameter in a CLI command.

You might want to check access control in the validation phase,
before anything in the target config is actually touched.
If you don't have a non-destructive validation phase, then
you have to do a rollback-on-error (if supported and requested).

Andy

---

From: Vincent Cridlig <[email-masked]>
Date: Mon, 18 Sep 2006 17:33:38 +0200

Andy Bierman a écrit :
> Vincent Cridlig wrote:
>> Hello,
>>
>> I have the same problem.
>> We control access before calling MIB modules for executing the 
>> request. The reason is that we don't want each module to implement 
>> access control. This is too costly.
>> The second reason is that if several modules have to be called for 
>> the same request and one module decides that access should be denied, 
>> we have to rollback the other modules.
>>
>
> from the root to every leaf node.

I would argue that it depends a lot on how you specified your access 
control model, for example, if you specify permissions by subtrees, by 
MIB modules, ... rather than by nodes.

>   This is no different

I fully agree with you on that.
My only wish is to make the MIB module developement as easy as possible, 
meaning no access control knowledge within modules.
Of course, my position may be very specific to our implementation ;-)

Regards,
Vincent

>> And we specify as precisely as possible the requests on the manager 
>> side (using the operation attribute).
>>
>> Regards,
>> Vincent
>>
>> Balazs Lengyel a écrit :
>>> Hello,
>>> incoming RPC, the userID/group and his access control rights; 
>>> without a need to know what is already in the datastore. However if 
>>> I get a request like (in approximate netconf):
>>>
>>> and the user has read rights on all parts of the data model but 
>>> write rights only on the adminstate but not on the interface level I 
>>> have a problem.
>>> possibilities is a complex thing to implement. In some cases it 
>>> would be enough to allow only "null" as a default operation and only 
>>> create/delete (and maybe replace) as subsequent operations. This 
>>> would make life much easier for some nodes. Sadly merge is mandatory 
>>> in the draft.
>>>
>>>
>>> Andy Bierman wrote:

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 18 Sep 2006 17:43:29 +0200

Hello,
Does this mean, that in your opinion it is NOT Possible to do access control without the 
information: what is stored already in the datastore?
Balazs

---

From: Phil Shafer <[email-masked]>
Date: Mon, 18 Sep 2006 11:59:36 -0400

>information: what is stored already in the datastore?

You shouldn't need the datastore to do access control, but you
might need the schema and the user's permissions.  In JUNOS, we
try to leverage the normal CLI permissions, so if you can't
touch it (or view it) via the CLI, you can't touch/view it in
the API.  The schema that defines the data store contains
this access information, so both the CLI, the API, the web goo,
and whatever else can eat your schema will be able to understand
and enforce your permission scheme.

Thanks,
 Phil

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 18 Sep 2006 09:50:06 -0700

Hi -

> From: "Balazs Lengyel" <[email-masked]>
> To: "Andy Bierman" <[email-masked]>
> Cc: "Vincent Cridlig" <[email-masked]>; "'Netconf (E-mail)'" <[email-masked]>
> Sent: Monday, September 18, 2006 8:43 AM
> Subject: Re: Access control
...
> information: what is stored already in the datastore?
...

Yes, for the example you gave.
This is a direct consequence of the way edit-config merge
is defined, and of the of access control requirement to distinguish
creation of an object instance from the modification of an objects'
attributes.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Sep 2006 10:13:30 -0700

> creation of an object instance from the modification of an objects'

This depends on the "operation" and how that is represented
in the access control model.

If you wanted a model that uses the NETCONF operation set
(merge, replace, edit, delete) then you have to look at the
datastore during validation at some point anyway to process
an <edit-config> PDU already.

If your access control operation set is simply (read, write)
then you do not need to look at the datastore to enfore access
control.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 19 Sep 2006 08:15:41 +0200

I want just read, write controls still I don't know how to handle the merge example.
Balazs

Andy Bierman wrote:
>>> Does this mean, that in your opinion it is NOT Possible to do access 
>>> control without the information: what is stored already in the 
>>> datastore?
>> ...
>>

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 19 Sep 2006 09:30:41 +0200 (CEST)

>        <adminstate>Up</adminstate>

since the merge on <interface-eth0> will create it if it doesn't
exist.

I don't see the big problem though.

As an alternative, you could deny the merge request if the user
doesn't have write access, and force her to use explicit operations.

/martin