Re: same value operation attributes restriction

[Andy Bierman <abierman@cisco.com>]

At 01:02 PM 3/27/2004, Juergen Schoenwaelder wrote:
>On Fri, Mar 26, 2004 at 04:15:00PM -0800, Andy Bierman wrote:
>
>> >5) The application code is less complicated if multiple operation 
>> >   attribute values are permitted: 
>> >
>> >GG: The complexity shift in your example is brought by the specific 
>> >    case of the transaction-per-PDU model.  The resolution of the complexity is 
>> >    not in the NetConf encoding, it is in the device's handling of the 
>> >    transaction model.  If the device does not support rollback-on-error 
>> >    nor multi-PDU transactions, then the user must figure out the undo whatever 
>> >    the encoding (though it's probably harder to know what to undo in the 
>> >    mixed-operation model as it is not clear up to where the encoded data-structure 
>> >    was processed without analyzing the rpc-error blocks -- which might not be 
>> >    as simple as it seems).  In anycase,  my argument about the 
>> >    complexity was not about the model but about the encoding.  It was not about 
>> >    how the commands are sent but how the commands are encoded. 
>> >    I never argued against the mixed-operation model but only that NetConf 
>> >    must define how it is to be encoded if it is going to be supported. 
>> >    I'm just saying that I believe an operation-dominant encoding is simpler to use 
>> >    mechanically than one that sprinkles operations all over a data-structure. 
>> >                action data... 
>> >                action data... 
>> >    is more straight forward than 
>> >                data 
>> >                        data (action) 
>> >                                data 
>> >                                        data (action) 
>> >                        data 
>> >                data (action)... 
>> >    If one has to adopt a data-dominant encoding, I bet they will prefer to 
>> >    just re-encode the whole component in one shot rather than try encode 
>> >    a data structure that contains both new data (the added and set stuff) and 
>> >    old data (the stuff to be deleted) [that's the traditional FTP model]. 
>> >    The transaction-per-PDU model could be supported in a operation-dominant 
>> >    encoding simply by listing the individual operations to be performed 
>> >    within one PDU (e.g. edit-config as a list of add/delete/set elements with 
>> >    the target data structure as sub-element to each).  
>> >    Functionaly, this is the same as the data-dominant encoding 
>> >    in the sense that it produces the same results but it is much simpler to produce 
>> >    mechanically.  In that sense, If NetConf is going to specify how the 
>> >    operations are encoded, I sure hope is will be with an action-dominant model. 
>> 
>> I disagree.  Customers have asked for the
>> ability to submit a group of config changes and
>> perform all of them or none of them.  Complex atomic
>> operations would be ideal, but rollback-on-error is
>> good enough.  
>> 
>> If we restrict netconf payloads to single, simple operations,
>> it will be impossible to deliver this feature to customers
>> using netconf. 
>
>Andy, I fail to see how your response has anything to do with the
>subject of the text you are responding to. It seems you just do not 
>want to listen and discuss the technical issue.

I don't accept your assumption that the device won't
have rollback-on-error capability.  I agree that
without this capability, the 2 approaches work
out about the same.  But with this capability,
approach A is clearly better.

I also disagree with the characterization that approach A
is "sprinkles operations all over a data-structure".
It is very easy to come up with use cases
for mixing operation attributes in a single edit PDU,
to represent a coherent high-level operation.

Just consider a service to be configured which requires
that some global (top-level) config data be created,
as well as some interface-level config data be modified.
That's a create and a modify that needs to be done
together if rollback-on-error is going to be worth using.
It's extremely common for router features to have config 
data at both the global and interface level.   

My concern is that if we use the "action data" design to
achieve architectural purity, we will severely hinder
operational usability.  We will force operators to use
merge or replace instead of create and modify.  We will
force operators to write more complex scripts that
can't take advantage of the netconf rollback feature.


>[Thanks to GG for this nice write up of the issue.]
>
>/js

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