Re: nested operation attribute interoperability

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

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.

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



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