[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Explicit and unique naming of configuration target
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.
> 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.
--
Weijing Chen
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/>