Re: Methods, data hiding, and friends

[Andy Bierman <ietf@andybierman.com>]

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



> 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
> dharrington@huawei.com 
> dbharrington@comcast.net
> ietfdbh@comcast.net
>
>
>
>
>
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
>
>
>   



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