Subject: [Netconf] when is merge really an operation?

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Jun 2010 10:00:11 -0700

Hi,

An implementor issue has come up that affects NACM and partial-lock.
It has to do with the definition of a merge operation wrt/ the
unaffected nodes contained within the operation.

1) initial state -- partial-lock(select='/p-container') by session A

  <config>
    <p-container />
  </config>

2) session A adds an unlocked leaf: /p-container/leaf='42'

   <config>
     <p-container>
       <leaf>42</leaf>
     </p-container>
   </config>

3) session B changes the new leaf: /p-container/leaf='17'
   how this is done is important:
 
   a) default-operation='merge'
   b) default-operation='none'

   <edit-config>
     ...//other parms
     <config>
        <p-container>
           <leaf nc:operation='merge'>17</leaf>
        </p-container>
     </config>
   </edit-config>

Clearly, for case (b), the only operation requested is a merge
on the unlocked leaf.

The part that is not clear is whether case (a) constitutes
a merge operation request on the /p-container node.  If so,
then it seems the partial-lock 'in-use' error, or a possible
NACM 'access-denied' error is possible.  If not, then the
merge operation on 'leaf' will succeed.

Our server implements (b), not (a).  The client can still use
default-operation='merge' (or even 'replace', or even copy-config!)
and only 'real' operation requests are examined.  The server
has to 'diff' the request node with the target node, and figure
out if a real change is pending or not.  Unaffected nodes
are not disturbed.

>From my reading of RFC 5717, it seems like (a) is supposed
to cause an error, not be allowed,  but it is not clear.
Does anybody know?  Does NACM need to work the same way as
partial-lock or not?

thanks,
Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 23 Jun 2010 19:38:54 +0200 (CEST)

Hi,

> 3) session B changes the new leaf: /p-container/leaf='17'

This cannot be done.  All nodes under /p-container are part of the
"protected area" covered by the partial lock, and thus this request
will fail with tag 'in-use'.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 23 Jun 2010 11:06:52 -0700

>From 5717, sec. 2.4.1

   When a NETCONF session holds a lock on a node, no other session or
   non-NETCONF mechanism of the system can change that node or any node
   in the hierarchy of nodes beneath it.

OK, but...
It is not clear that this includes descendant nodes of a locked
node that do not exist yet because of para 3.  But I prefer
your interpretation.  I remember from WG discussions
that new nodes were not part of the lock, and this was
supposed to be a feature.  Perhaps I wasn't paying enough attention.

   The XPath expressions are evaluated only once: at lock time.
   Thereafter, the scope of the lock is maintained as a set of nodes,
   i.e., the returned nodeset, and not by the XPath expression.  If the
   configuration data is later altered in a way that would make the
   original XPath expressions evaluate to a different set of nodes, this
   does not affect the scope of the partial lock.

Again, it is not clear that creation of a descendant node of
a node affected by the partial-lock is part of the existing lock or not.

   Let's say the agent's data model includes a list of interface nodes.
   If the XPath expression in the partial-lock operation covers all
   interface nodes at locking, the scope of the lock will be maintained
   as the list of interface nodes at the time when the lock was granted.
   If someone later creates a new interface, this new interface will not
   be included in the locked-nodes list created previously so the new
   interface will not be locked.

This is ambiguous because there is no specific mention of the actual
NETCONF operations, or whether sibling nodes are involved, etc.
IMO, this key paragraph suggests that new nodes created after the lock
expression was evaluated are not part of the lock.

IMO, this would make it more clear:
Para 3:  Add operation:

   <rpc>
      <partial-lock>
        <select>//interface</select>
      </partial-lock>
   </rpc>

   <rpc-reply>
      <lock-id>124</lock-id>
      <locked-node>/interfaces/interface[name='eth0']</locked-node>
      <locked-node>/interfaces/interface[name='eth1']</locked-node>
   </rpc-reply>

Add explanation that new siblings which would have matched the expression.
e.g., /interfaces/interface[name='eth2'], are not locked.

It is also not clear, even if /p-container is locked in my example,
that RFC 5717 handles the case where default-operation='none'
for some ancestor nodes of a node containing an operation attribute.

It is also not clear whether the server is allowed to normalize the
locked-node nodeset in the reply.

   <rpc>
      <partial-lock>
        <select>//interface</select>
        <select>//interface/mtu</select>
      </partial-lock>
   </rpc>

A server implementation may optimize out the 2nd select
since it has no affect.  The locked nodes with still be
the highest (closest to root) ancestor that is locked.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 23 Jun 2010 22:03:38 +0200 (CEST)

> supposed to be a feature.  Perhaps I wasn't paying enough attention.

5717 differentiates between "the scope" of the lock, and "the
protected area".  The scope of the lock are the nodes that are
selected at lock time.  These do not change; that's a feature :) The
protected area is all the subtrees rooted at all nodes in the scope of
the lock.  The nodes in the protected area changes if nodes are
created / deleted in these subtrees.  Maybe this could be made more
clear, but I don't think there is any text that suggests that newly
created nodes in the protected area would not still be protected.

An implementation can keep track of the nodes in the scope of the lock
only; if any request tries to modify a node underneath one of those
nodes, the request is rejected.

> for some ancestor nodes of a node containing an operation attribute.

Can you elaborate?

> the highest (closest to root) ancestor that is locked.

A server is of course allowed to make any optimizations -- as long as
they are opimizations that don't affect the end result.  I don't think
this has to be spelled out...

/martin