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

Re: nested operation attribute interoperability

Martin Bjorklund wrote:

Andy Bierman <ietf@andybierman.com> wrote:

Martin Bjorklund wrote:

I agree that top-down processing makes most sense (that's what we do
today). 
Let's approach the problem that way.
Let's remember (I didn't) that it is the contents
of the target configuration that matters, not the
child nodes within the PDU request, when testing the
edit operation for the current node.



So, what should the table be?  Like this maybe

child ->  create   merge   replace   delete
parent
  |

 none      V        V        V         V

create     x        V        V         E-1

merge      V        x        V         V

replace    V        V        x         E-1

delete     E-1      V        E-1       x

merge and replace are not really different in these nesting cases.
Your E-1 for replace-delete and delete-replace seem wrong
because there is no existence test for replace.


If replace-delete is interpreted as "first replace parent. then, while
doing the replace, delete the child", the "delete the child" will fail
with data-missing.

delete-replace... first delete the parent, then replace the child.  If
this does not generate an error, the child would actually be created.
Same goes for delete-merge if this interpretation is used.  So maybe
an error should be generated even for delete-merge.


1) only 'create' and 'delete' have any kind of existence tests.
   Merge and replace can always work and never generate an error because
   of data present or missing in the target configuration.

2) The 'create' and 'delete' tests apply to the target data models,
   not to the content of the edit-config PDU.  The test is not done
   against the PDU at all.  Doing the tests bottom-up will not change
   anything, because the target data models have not been modified yet.

3) Any operations under a 'delete' within the PDU are academic.
   They only serve to complicate test-suites, and have no operational
   value.  What matters is the state the target config when you are done.
   If an operation to delete <foo> is going to succeed, then
   the 'activity' in the PDU for children of <foo> is irrelevant.
   (Although not to the error reporting rules.)








The E-1 on delete under replace would be motivated by the fact that
replace is first delete, then create.  So it should give the same
error as delete under create.

The only question mark is maybe the last row.   Why should merge under
delete be allowed?  (maybe for convenience; default operation is
'merge', and with this you can do:

   <user operation="delete">
      <name>fred</name>
   </user>


No -- operations affect the current node and all its children.
The operation for <name> is 'delete'.


You're right.

(But is this obvious from the text?  Is it this sentence from 7.2 that
defines this behaviour:

    The attribute identifies the point in the configuration to perform
    the operation,
)



Top-down processing works:
If there are no <user> nodes in the target data model, then it
doesn't matter if <name> is present or not -- it is still a
data-missing error as soon as <user> is processed.

Since the operation in effect at the next node is a delete on the
selection node 'fred', if the <user> node did exist, but the entry
for 'fred' did not exist, the delete test for name=fred fails,
and a data-missing error is correctly generated.

If you really did have:

<user operation="delete">
    <name operation="replace">fred</name>
</user>

This 'replace' would be a NO-OP (V-2 as I interpreted it).
Since 'replace' and 'merge' do not have existence test errors,
there is no error generated even if the 'replace' attribute
is processed.  The end result is that the target data model
is deleted, starting from the node that 'delete' is first seen.
(Further processing for selection nodes is required of course.)


But this must also depend on the data model.

If name is key in user, this would delete the user fred:

<user operation="delete">
    <name>fred</name>
</user>
But this wouldn't delete all admin users, would it? 


There is nothing in the protocol that actually says the
construct above means "delete the entry named fred".
Your agent just has to know to look for the naming elements
if the NMS is deleting multiple-instanced nodes this way.




<user operation="delete">
    <type>admin</type>
</user>

Unless you apply some kind of subtree filtering semantics on the
delete.


There are no data modeling rules yet, so you can experiment
and figure out what works best.  I don't see why you couldn't
do something like this.  However, this is not a subtree filter,
and the agent is not obliged to treat it as one.

I was the one who originally pushed hard against the idea
of multiple operation attributes in the <config> subtree, because
I knew there were many more unintended consequences than
benefits in this design approach.

I think you were the one that suggested using xpath expressions
instead of these subtrees. E.g.,

 <rpc>
   <delete target="/users/user[name='fred']"/>
 </rpc>

I am starting to think it would be easier to constrain xpath
than the subtree approach, in order to minimize the dev-effort required
to properly report corner-case errors, and reduce the number
of operationally worthless corner-cases.






/martin


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