RE: Explicit and unique naming of configuration target

[Andy Bierman <abierman@cisco.com>]

At 06:45 AM 5/23/2003, Glenn Waters wrote:

>I also agree with Larry and Jeurgen on this point. The semantics of the protocol need to distinguish between create and modify.
>
>Andy, with respect to your statement that "the client should know the state of the device" I think that the complexity is much greater than you may think. When you get into systems that programmatically handle the configuration of the device it can be very challenging to know the state of the device; especially when other systems and other humans may be modifying the device at the same time.

I agree (and said this before) that the protocol should have
distinct create, modify, and delete operations.  The issue
is how that is done.  My concern with putting operations at
the attribute level is the extra complexity on the device
in supporting unlimited combinations of operations.

I am not at all convinced that this proposal to be able
to create a sub-element within a parent (but only if
the parent exists) removes the need for locking or
the need for the client to understand the state of the
device before modifying the configuration.

For example, what if the client was adding an IPv6 address to
an interface (but only if it exists), but the interface
already had an IPv4 address.  The operation succeeds.
The device deletes the IPv4 address and replaces it with 
the IPv6 address.  This looks like success to the client,
but not to a different client that had previously set up
the IPv4 address.   You can't just blindly change config
without understanding its current state.


>Regards, /gww  

Andy


>> -----Original Message----- 
>> From: Juergen Schoenwaelder [<mailto:schoenw@ibr.cs.tu-bs.de>mailto:schoenw@ibr.cs.tu-bs.de] 
>> Sent: Friday, May 23, 2003 02:59 
>> To: abierman@cisco.com; lmenten@lucent.com 
>> Cc: netconf@ops.ietf.org 
>> Subject: Re: Explicit and unique naming of configuration target 
>> 
>> 
>> >>>>> Andy Bierman writes: 
>> 
>> Andy> Why would the client want an MD5 key added to an interface, but 
>> Andy> not want the interface to be created, if necessary?  This seems 
>> Andy> to be optimizing for a corner-case.  The client should check if 
>> Andy> the interface exists if it's that important.  I don't think it's 
>> Andy> unreasonable for the client to know the state of the device 
>> Andy> before modifying the device config.  I view the 'add MD5 key' as 
>> Andy> a modify, not an add. 
>> 
>> If I understand the discussion, then Larry basically wants to be able 
>> to make a clear distinction whether an <add-config> requires some base 
>> instance to exist already (and to fail if it does not) or whether the 
>> requests also asks the device to create a base instance with default 
>> settings if it does not exist. I tend to agree that such a distinction 
>> is important since the effects on the device are quite different. 
>> 
>> I also heard Larry saying that he prefers to explicitely select the 
>> instance(s) an operation is supposed to work on by passing e.g. an 
>> xpath expression which selects the relevant object instances. 
>> 
>> Larry, did I understand you correctly? 
>> 
>> /js 
>> 
>> -- 
>> Juergen Schoenwaelder         International University Bremen 
>> Phone: +49 421 200 3587               P.O. Box 750 561, 28725 Bremen, Germany 
>> Fax:   +49 421 200 3103               <<http://www.iu-bremen.de/>http://www.iu-bremen.de/> 
>> 
>> -- 
>> 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/>