[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: same value operation attributes restriction
At 03:52 PM 3/25/2004, Gilbert Gagnon wrote:
I think you are missing some of the points I am trying to make.
1) Data model designers do not get to define their own set
of operations. They specify exactly how the standard
set of 5 operations applies to their data model. Big difference.
2) Application programmers are not forced to use multiple
operation attributes within a single edit-config PDU.
3) It is quite easy to come up with use cases for using different
operation attribute values within the edit-config PDU,
especially if the rollback-on-error error-option is used.
4) For devices that allow writes to the running config, the
operation sequence matters because the running config is
not an abstract datastore. Network behavior is affected
immediately, so N sequential edit-config PDUs does
not necessarily yield the exact same results as 1 edit-config
PDU that combines the changes embodied in N operations.
5) The application code is less complicated if multiple operation
attribute values are permitted:
A) 3 operations in 1 PDU, using operation attribute:
M = create_msg(target=running, error-option=rollback-on-error,
<config>
<foo operation="create"> .... </foo>
<goo operation="replace"> .... </goo>
<boo operation="modify"> .... </boo>
</config);
err = send_rpc(M, IP-host-X);
if (err != NO_ERR)
cleanup and exit;
B) 1 operation in each of 3 PDUs, using explicit message type
for each of the operation types:
M1 = create_msg(op=create, target=running,
error-option=rollback-on-error,
<config>
<foo> .... </foo>
</config);
err = send_rpc(M1, IP-host-X);
if (err != NO_ERR)
cleanup and exit;
M2 = create_msg(op=replace, target=running,
error-option=rollback-on-error,
<config>
<goo> .... </goo>
</config);
err = send_rpc(M2, IP-host-X);
if (err != NO_ERR) {
first, figure out how to manually undo M1;
this probably requires that the state of <foo> before M1
must be saved;
create_msg(undo-M1, ...)
err = send_rpc(undo-M1, ...)
cleanup and exit;
}
M3 = create_msg(op=modify, target=running,
error-option=rollback-on-error,
<config>
<boo> .... </boo>
</config);
err = send_rpc(M3, IP-host-X);
if (err != NO_ERR) {
first, figure out how to manually undo M1;
this probably requires that the state of <foo> before M1
must be saved;
create_msg(undo-M1, ...)
err = send_rpc(undo-M1, ...)
if (err != NO_ERR)
you're hosed; figure out how to recover
then, figure out how to manually undo M2;
this probably requires that the state of <goo> before M2
must be saved;
create_msg(undo-M2, ...)
err = send_rpc(undo-M2, ...)
if (err != NO_ERR)
you're hosed; figure out how to recover
cleanup and exit;
}
I don't understand how approach B could ever be considered
easier to use, easier to understand, or less disruptive
to the network behavior than approach A.
Note that approach A is not the same as compound operations
because all the parameters are shared and therefore must
be the same, and only the edit-config PDU is allowed to
appear in the RPC. Compound operations could have different
parameter values or even different operations (e.g., lock,
get-config, validate) within the same RPC.
Andy
>Hello,
>
>Just a few remote comments on where this discussions seems to be going...
>It seems that NetConf is sliping into something less than was originally
>intended (as much as I could deduce the intent from the RFC).
>If we defer every operation decision to the "data model"
>(the payload of the NetConf messages) then what is the value of NetConf then?
>Doesn't it just become yet another "generic" RPC protocol? What benefits would
>it then offer over other RPC/envelope techniques like SOAP?...
>It seems to me that one of the benefit of NetConf was to define a common framework for
>device management. This does not mean that there would be only one operational
>model for it. I can readily imagine that the protocol could define both
>a merge type of model (where a component structure is merged with the
>device's configuration) and an action-oriented model (where separate messages
>are used to perform specific actions on the model like add, set and delete).
>One solution does not fit all.
>
>On the other hand, letting the individual
>device data-model decide both on the structure of the data and the operations
>on it seems to make the protocol impotent... Applications will have to be created for
>each device type separately. I can see how one can data-drive the manipulation
>of the data-structures (schemas). I'm not as clear on how one data-drives the
>processing of the data (semantics). There has to be something recognizable
>(standardized) in the model to look for (i.e. this is how "adding" is encoded,
>this is how "changing" is encoded, ...). If the operations are relegated
>to the data-model, I'm convinced NetConf will have to define guidelines for that
>model...
>
>I'm also quite worried about thinking of the XML structures in too theoretic a
>way. Yes, I can imagine how one would have and edit-config operation with
>operation markers embedded in it to say what gets added, changed and deleted.
>On the other hand I dont see well how that can be used pratically...
>It's not an obvious thing to construct at all... I expect the vast majority
>of use will be to have separate messages to delete, set, and add stuff.
>In that case, encoding the editing operation in the data-structure itself
>(though workable) looks quite goofy... (in fact the actual naming of components
>as full hierarchical embedded XML elements is also not that "optimal"...).
>Alternatively (as has been raised earlier) if the preference is to
>extract the component structure (show-config), modify it, and dump it all
>back to the device to replace the existing one, then you don't really need
>fancy operation markup... on the other hand, what you then have
>is just another form of FTP... (and I have my worries about long
>payloads in the SSH transport...).
>
>So, in conclusion since I'm sure I was too confusing above, I think that
>1) NetConf would be better to define the operational aspects of the configuration
> (adding, setting, deleting, loading, ...),
>2) I would prefer those operations would be encoded in the NetConf message itself,
> not inside the data-structures,
>3) If they are inside the data-structure, then I think NetConf must define
> the way they are presented (which probably implies that NetConf would have
> to define the structure of that data-model...).
>
>Without this, I expect NetConf will be little else than an RPC protocol with
>fancy XML payloads that help little with management inter-working. Not necessarily
>useless but not what I thought the intent was.
>
>Thanks
>
>P.S. I worded things in terms of the editing operations (add, set, delete) but
>I think they also apply in many ways to the show operations (configuration
>vs operational).
>
>-----Original Message-----
>From: Andy Bierman [<mailto:abierman@cisco.com>mailto:abierman@cisco.com]
>Sent: Thursday, March 25, 2004 10:43 AM
>To: Waters, Glenn [CAR:IO47:EXCH]
>Cc: j.schoenwaelder@iu-bremen.de; netconf@ops.ietf.org
>Subject: RE: same value operation attributes restriction
>
>At 07:14 AM 3/25/2004, Glenn Waters wrote:
>
>>> I want to have some chance at multi-vendor interoperability.
>>> If we don't specify how the protocol allows a configuration
>>> database to be manipulated, then developers won't know what
>>> to code. We have a set of operations (create, modify, merge,
>>> replace, delete) with well understood semantics. I don't
>>> see how this is a CLR.
>>
>>I agree that we need to specify the type of update.
>>
>>I understand create and delete.
>>
>>I don't understand the difference between replace, modify, and merge.
>>
>>Is replace just a delete following by a create? If so why not eliminate
>>it.
>
>Because it's one operation, not two.
>This is better because it can make some tasks easier to code for the application developer.
>
>Modify will fail if the indicated data does not already exist. This is useful for access control and to enforce stricter programming practices than merge or replace.
>
>>I think we need the equivalent of the SQL "update" which I guess is
>>modify or merge but I don't understand the difference between those
>>two. Also, to use existing industry terminology why not use the keyword
>>"update".
>
>Update is very generic. Counters get updated too.
>I don't care very much about terminology, other than
>a strong desire to avoid ratholing over it.
>
>>Regards, /gww
>
>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/>http://ops.ietf.org/lists/netconf/>
--
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/>