Re: nested operation attribute interoperability

[Andy Bierman <ietf@andybierman.com>]

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.


> 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'.

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.)




> to delete the fred user, if <name> is used as key.)
>
>
>
> /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/>