RE: Explicit and unique naming of configuration target

[Andy Bierman <abierman@cisco.com>]

At 02:54 PM 5/23/2003, Chen, Weijing wrote:
>Andy Bierman wrote:
>> 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.
>>
>The operation must associate with the most immediate element of intended
>operation to avoid the ambigious.  Otherwise even with complex rules
>regarding operation (e.g. "get" apply to last element, or last 3 elements,
>or last 7 elements plus one of left sibling if blabla, etc.), one still have
>cases fall outside the rules.

what's to prevent multiple, possibly conflicting operations
on various elements at various levels of the sub-tree?


>> 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.
>>
>You have a poorly designed XML schema data model then.  You should have two
>sub-elements (or two attributes):  one for IPv4 address, one for IPv6
>address. Or one sub-element (or one attribute) with union type: choice of
>IPv4 address or IPv6 address.  Also the device need to send a update
>notification to second client if second client so concerns about the update
>made by first client.

I disagree.  This will be a common schema design, where a <choice>
element (basically a union) is used to allow for different forms
of a basic parameter, such as an IP address.  

One could argue that the protocol should force the client
to use a <modify> operation in order to change the address
from a IPv4 variant to an IPv6 variant, instead of a <create>
operation.  IMO, either way, the client needs to know the
exact state of the device in order to construct the correct
PDU.  

I wouldn't mind operations-as-attributes if there is a way
to constrain it and keep device implementation complexity
low.   When I see emails containing suggestions that the
client should be able to mix read operations with write
operations (for arbitrary parameters), or proposals using
nested XPath expressions, I don't get a sense that 
constraining complexity is a universally shared goal.




>--
>
>Weijing Chen

Andy



>SBC Laboratories, Inc.
>
>9505 Arboretum Blvd.
>
>Austin, TX 78759
>
>512 372 5710
>
>wchen@tri.sbc.com
>
>
>> -----Original Message-----
>> From: Andy Bierman [mailto:abierman@cisco.com]
>> Sent: Friday, May 23, 2003 11:29 AM
>> To: Glenn Waters
>> Cc: Juergen Schoenwaelder; lmenten@lucent.com; netconf@ops.ietf.org
>> Subject: RE: Explicit and unique naming of configuration target
>> 
>> 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/> 


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