[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: same value operation attributes restriction
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.
[Thanks to GG for this nice write up of the issue.]
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany
--
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/>