[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: action RPC I-D

Balazs Lengyel wrote:

Hello,
My point with the action draft was not to provide an access control solution, but to provide a way to transfer non-standard action type commands/operations to the Netconf server. I believe I showed that my draft will not have problems with access control as there is a place (the data model) to put access control characteristics/information about an individual action.
So I would still like the group to consider my generic action draft. I would like to 
promote it into a workgroup document.


I do not think the WG wants the extra layer for RPC methods
that have a purpose which is characterized as an action.
There has been some support for defining some standard actions
which use the existing RPC mechanism.

IMO, basing a protocol feature on presumed implementation
advantages for intermediate systems will be difficult to
achieve, unless there is widespread use of some tools that
actually need the data in this format.  This made sense
for the SOAP wrapper for NETCONF because there are many
pre-existing tools which expect the data in a certain format.

The same is not true for this new 'action' RPC wrapper.
Several people have stated that this new wrapper will not
make their code any easier to write.  Some have stated
that it will actually make some tasks much harder
if hard-wired element names (like <ping>) are moved to
string content instead.

I think the WG members who want to change the RPC mechanism
in this manner need to speak up on the mailing list.

In the meantime, we have only one chartered work item,
which is not finished.  Any new work will require a change to
the charter.



Balazs



Andy


Andy Bierman wrote:

Balazs Lengyel wrote:

Hello,
You are right, we need access control.
For this reason each action defined in the data model should be defined as read/write/disturb-traffic. read: it only reads configuration and state data and doesn't effect the traffic 
write: it writes configuration data, but does not disturb the traffic
disturb-traffic: means it can do anything.


IMO, a clean access control model for NETCONF need to recognize
the RPC model and the configuration datastore architecture.

First, there is the RPC method, defined by a QName.
The user must have access to invoke the RPC method.

Completely independent of that is the data access control model
applied to all configuration datastores.  The NETCONF operations
are create, delete, merge, and replace.  For access control purposes,
merge and replace operations are treated as a 'create' if the target
data instance does not exist.

The granularity could be a coarse as read/write, but that would
totally defeat the purpose of create and delete operations in
the edit-config method.  An access control that matches the
capabilities of the protocol needs to include read/write/create+delete
as the 3 levels of data access (4 if you count 'none').

It makes no sense to have an 'exec' or 'disturb-traffic' access
control classification in the data space.  Either the user can
invoke the RPC method or not.  Remember, it is the PROTOCOL that
needs an access control model, not blobs of XML.  IMO, focusing the ACM
on the XML is the wrong approach.
One can debate that these are the good categories for access control. Still the basic statement is that for each action defined in the data model you need to specify it's access properties in the data model as well. 
Balazs

Andy Bierman wrote:

Your access control model should be more robust than
simply allowing user X to do anything called <action>.
I don't see what benefit an intermediate SW component
can realize if an extra generic container is added to <rpc>.







Andy






--
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/>