Subject: [Netconf] enforcing NACM top-down

From: Andy Bierman <[email-masked]>
Date: Mon, 22 Mar 2010 23:53:58 -0700

Hi,

I got some offline comments about applying access control
in a hierarchical manner.  I think NACM is different
than a unix file system model...

The NACM design is somewhat tied to
the edit-config design for nc:operation (starting
with default-operation and checking for nc:operation
to alter the inherited operation).

The current tree has to be used as part of the
algorithm.  Only real operations are checked,
e.g., merge/replace is only real if the new tree
alters the current tree at that node.

   merge /x/y/z value=10   # set 'z' to 10

   <edit-config>
     <target><running/></target>
     <default-operation>none</default-operation>
     <config>
       <x>
          <y>
             <z nc:operation="merge">10</z>
          </y>
       </x>
     </config>
   </edit-config>

According to NETCONF, /x and /x/y must already exist.

This may be encoded in an edit-config
in many ways, using different default-operation values
and selecting where the nc:operation='merge' attribute is located.
The most conservative operation is shown above, but the default
is 'merge':

   <edit-config>
     <target><running/></target>
     <default-operation>merge</default-operation>
     <config>
       <x>
          <y>
             <z>10</z>
          </y>
       </x>
     </config>
   </edit-config>

In this variant of the edit=config operation, the
user is technically requesting a merge on /x and /x/y.
In NACM, this is only a real operation request if
the target node is actually going to change.

My point is that access control is top-down according
to the protocol.  Via edit-config you can specify the
start node deep in the tree, and via copy-config
you can only rely on starting at every top-layer data node.

copy-config/replace is harder to check because a diff of /x and /x/y
may be needed to determine the true starting node of the
replace operation.  The standard does not require this
at all for copy-config, and I doubt if servers implement this consistently.

I don't think we can (or want to) really change these NETCONF concepts.
I don't see how to interpret a NETCONF operation on
QName 'z', rather than data node /x/y/z.

Andy