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