Re: nested operation attribute interoperability

[Andy Bierman <ietf@andybierman.com>]

Martin Bjorklund wrote:
> Andy Bierman <ietf@andybierman.com> wrote:
> > Hi,
> >
> > I am trying to create an matrix to help me optimize code
> > related to the processing of the nested operation attribute.
> > It would be nice if vendors handled this in an interoperable manner.
>
> Absolutely.
>
> > I try to follow the Postel Principle and not generate any
> > errors unless it is mandatory.  I use containers to make
> > it easy to apply a 'delete' operation to an entire table,
> > as well as easier access control configuration.
> >
> > At any given point in a <config> subtree, there is a 'parent'
> > edit operation and a potentially different 'child' edit op.
> > Obviously the parent edit-op has precedence.  The start state
> > is allowed to be 'none', but once the operation is set, it can
> > never go back to 'none'.
> >
> > This table shows each parent --> child edit-op transition,
> > and whether it is valid or an error.  My question to the WG
> > is whether this table is correct or not:
> >
> > child ->  create   merge   replace   delete
> > parent
> >     |
> >  
> >    none      V        V        V         V
> >  
> >   create     x        V-1      V-1       E-1
> >
> >   merge      V-3      x        V         V-3    
> >
> >   replace    V-3      V        x         V-3
> >
> >   delete     E-1      V-2      V-2       x
>
> Our table is a bit different, and I think the reason is b/c you have a
> different meaning of the operation 'replace' than us (and others such
> as juniper).  This has been discussed before (see the thread "Second
> Example in section 7.2 of netconf-proto").  Your 'replace' is more of
> a 'merge'.  Personally I think it is even more important to have an
> interopable interpretation of the meaning of these operations.


No -- we decided your interpretation of replace is correct.
I am changing my code for replace to match it.


> Anyway, this would be our table, differencies to yours are marked with
> (*):
>
> child ->  create   merge   replace   delete
> parent
>     |
>  
>    none      V        V        V         V
>  
>   create     x        V-1      E-1(*)    E-1
>
>   merge      V-3      x        V-4(*)    V-3    
>
>   replace    E-1(*)   V        x         E-1(*)
>
>   delete     E-1      V-2      E-1(*)    x
>
>
> > Notes:
> >
> > V:    valid, no errors or warnings
> >
> > V-1:  valid, but create has precedence.
> >       Only merge-with-nothing or replace-nothing scenarios are valid.
> >
> > V-2:  valid, but has no effect because delete has precedence
> >
> > V-3:  valid, but create or delete rules now in affect for next child
> >
> > E-1:  'bad-attribute' or 'operation-failed' error (not sure which)
> >       Requirements for create and delete cannot both be met
> >       in the same subtree, regardless of the data model



I think your E-1 is wrong.
If the current subtree is empty, then replace is the
same as create.  My E-1 is only valid for merge or
replace if it is also valid for create.

Replace does not fail if there is nothing to replace.
Only delete fails if there is nothing to delete,
or create fails if the data is already there.


> >   x:  no edit-op change
>
> V-4:   valid, but replace rule now in affect for next child
>
> For errors (E-1), we use 'bad-attribute'.  (currently with error-type
> 'application', which I think might be wrong, it should probably be
> 'protocol'.  Deciding correct error-type is sometimes tricky...)
>
>
> /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/>