Re: nested operation attribute interoperability

[Martin Bjorklund <mbj@tail-f.com>]

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.


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

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

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


/martin

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