Subject: Methods, data hiding, and friends

From: "David Harrington" <[email-masked]>
Date: Sat, 4 Nov 2006 01:04:40 -0500

Hi,

I have some questions about the design of netconf data models and rpc
methods. I am going to go back to my comparison of programming
languages to describe the situation.

In SNMP, the small number of functions have direct access to any
variable anywhere in the MIB (scoped by a copntext of course). This is
very consistent with the apporoch used by assembly language, BASIC
(before structured BASIC was developed), C, and other procedural
languages. A major problem with the design of these languages was
side-effects; a given variable could be modified by one function, and
another function may not be aware when the data changed, and this led
to frequenetly-hard-to-locate bugs.

As object-oriented languages were developed, one desirable feature
that was included was data hiding. The actual implementation of the
data in an object was hidden behind methods. This offered the benefit
that an object implementation could change from an array to a linked
list or a hash table, and the consumer of the functionality proided by
the method call should never know the difference.

I view capabilities as similar to objects; they have some hidden data
associated with them, but the public interface is through a set of
special-RPC methods.

In O-O development, the software industry found a need to have things
like inheritance, private methods, and friend methods.

In netconf, a capability's method such as "create-vlan" may need to
manipulate the data elements of other capabilities, such as the
interface capability. Will methods of one capability be permitted to
directly modify the data of another capability, or will they be
constrained to utilize public and friend interface methods of the
other capabilities?

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

--
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: Phil Shafer <[email-masked]>
Date: Sun, 05 Nov 2006 23:39:57 -0500

"David Harrington" writes:
>languages.

This might be true if libc had only three functions (get, get-net, set).
Seen in this light, SNMP is more like early basics, where one could
peek and poke, based on the documentation, but never had a proper API.

>like inheritance, private methods, and friend methods.

And factories and overloading and interfaces and virtual functions
and templates and generics and other sources of endless training
courses (in popular vacation sites ;^)

>constrained to utilize public and friend interface methods of the

I see netconf as more like C, but that's probably because I like C.

A capability is like a library, with the functions as RPC methods
and the documentation as, well, documentation.  With a little IDL
work, one can make the functions appear as real RPCs to a C program,
so that "ping(host, size, timeout)" does the right thing.  (I admit
I had an easier time doing this in perl, with associative array
arguments and AUTOLOAD, but it works in C too.)

Thanks,
 Phil

---

From: Cridlig Vincent <[email-masked]>
Date: Mon, 06 Nov 2006 07:48:33 +0100

Hi

This comparison is interesting and I have a different but additional 
view on this:
I see the capabilities more in a package perspective. It is really 
similar to Linux packages since some capabilities need other 
capabilities. At some point, it should be possible to draw a dependences 
graph (or requirements graph).
For example, #validate capability requires the #candidate capability. Or 
if I develop an #xupdate capability, I should have the #xpath capability.
Also, when Netconf will have different releases of some capabilities, it 
will be good to have such description of the requirements (requires 
#xpath>=1.1).

As a consequence for hello exchange, this aspect could be used in two ways:
- discover capabilities inconsistencies (this entity advertises 
#validate but not #candidate => problem)
- only advertise the last levels of dependence (this entity advertises 
#validate so it supports #candidate for sure)

I think it is up to the capability developer to decide which parts of 
the API can be public and which must remain private. Anyway, in general, 
it might be very complicated to prevent a developer from using such 
method or external methods calls.

Regards,
Vincent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 06 Nov 2006 16:38:06 -0800

David Harrington wrote:

I use an RPC-based ACM, and consider service (or application) specific
RPC methods to be a critical part of the DM language. 

However, there is a disconnect between the efficiency of an OOA or SOA
method approach, and the desire to represent the entire configurable 
state of the NE
device in one textual file (e.g., show running config). 

You seem to be asking "Does the operator need to configure access control
on RPC methods and on configuration data as well?"  From a containment
POV< it doesn't matter if <create-vlan> calls <create-interface>.  You 
should
give access rights to create-vlan, based on the documentation of that 
RPC  method.

However, a generic gateway like <edit-config> cannot be properly secured
with just an RPC-based ACM, so a data model ACM is also needed (not
that I like this fact).  The actual configuration database is not 
relevant here
(i.e., <candidate> vs. <running>), just the conceptual data object 
boundaries
and instance names.  There is only one of these ACMs -- there is not one 
data ACM
for each RPC method.  This assumes all RPC methods operate on the same 
conceptual
set of configuration data -- i.e., there is only one data root.

There are services that probably can be efficiently managed just with 
<edit-config>,
but many that cannot.  Here are some more Qs:

Must all services allow all features to be managed with <edit-config>,
or can some features be accessed only by special RPC method? 

Must all state data be accessible with the <get> method? 

Must all config data be accessible with the <get-config>
(also, must <get-config> and <copy-config> produce exactly the
same output)?

How does private data get saved across reboots if the entire config
must be readable XML and be accessible through <get-config>?

Does private data mean that it is not accessible for writing through 
<edit-config>?

Does private data mean that it is not accessible for reading through 
<get-config>, <get>,
or <notification>?

Does private data imply that it is not accessible for saving through 
<commit> or <copy-config>?

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Nov 2006 05:13:12 +0100

> constrained to utilize public and friend interface methods of the

Netconf has evolved to take two different views of the world:

(1) A document-centric view where you use primitives like the powerful
    edit-config operation to make changes on a document describing a
    configuration.

(2) A function-centric view (or {method/operation/procecure/command}
    -centric view if you like these terms better) where you use
    special RPCs to invoke a certain function.

As a consequence, I believe we need to have an access control scheme
which supports a document-centric view and a function-centric
view.

The question was raised whether the access control for the
function-centric view is also subject to the access control for the
document-centric view (or view versa although people did not mention
this yet) and my personal answer to this question is "no". A function
"create-vlan" performs a certain well defined operation and I either
grant access for someone to perform this operation or I don't. The
value of a function such as "create-vlan" is that it hides the
implementation details and objects affected and I fear we loose the
benefits of hiding the details once we end up specifying which
"objects" are involved in the execution of such a function for access
control purposes.

Sure, this approach opens a window for "interesting" access control
configurations where "side effects" may be used to achieve something
using the function-centric view which you are not allowed to do via
the document-centric and vice versa. (For example, you disallow the
usage of the "create-vlan" function for some principal but the same
principal may still be able to create a vlan by playing with
"edit-config".) I assume that the price on the agent side for
preventing such situations is going to be high and thus I prefer to
push the handling of such situations to external tools that can
analyze and reason about access control rules. (Note that this is not
really something new. Even in the SNMP world, if I prevent access to
the interface table, someone might still create a VLAN interface using
her write access to the Q-BRIDGE-MIB::dot1qVlanStaticTable.)

BTW, I would like to have the flexibility to give one principal only
access to the document-centric view and another principal only access
to the function-centric view of a box. I believe that applications
(and most humans) will prefer one of the two views for a given task.
To create vlans, you likely prefer a "create-vlan" function; for
saving/restoring configs or for pushing a tested config change to many
boxes, you likely prefer edit-config. For testing config changes, you
might again prefer a function-centric view.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Cridlig Vincent <[email-masked]>
Date: Tue, 07 Nov 2006 08:37:55 +0100

> "objects" are involved in the execution of such a function for access

I fully agree. If people define new operations which have impact on the 
same objects as edit-config, they will probably need to specify for 
these operations the objects on which you need "write" privileges in 
order to perform a consistent access control. This can be done but it is 
one more constraint. If you have a dual access control, one for 
document-centric and one for function-centric, you introduce an 
important risk of inconsistencies.

What people can do also (since all implementations must support 
edit-config) is to generate an edit-config for this operation (like 
create-vlan) locally in the agent. And perform access control on it as 
for all edit-config operations. I think the function-centric approach 
should rely on the document-centric approach not only to avoid such 
access control mess, but also to have a single entry point for editing 
the configuration datastore. In most cases, such functions are typically 
macro-operations that can be decomposed into several atomic operations.

(Note that you could also have a create-vlan button and generate this 
edit-config on the manager side. This avoids to define new operations 
and also consumes less CPU in the agent side...)

> (and most humans) will prefer one of the two views for a given task.

What do you mean by most humans ? management application developers ? or 
human managers ?
If you mean "developer", the implementation choices (driven by 
simplicity reasons) will affect the privileges of the manager... It does 
not make sense.
If you mean "manager", I don't think a manager will ever write XML 
requests by hand, and therefore will never have to make a choice for 
document-centric or function-centric approach.

On what criteria can you decide that a principal has access to the 
document-centric or function-centric view ?

> might again prefer a function-centric view.

(IMO) In any case, the time when you translate the conceptual 
"create-vlan" to low level operations should happen before access 
control process. Otherwise, you may have consistency issues.

Regards,
Vincent