Re: A few potential requirements

[Mike MacFaden <mrm@riverstonenet.com>]

At 06:35 PM 6/26/01 -0400, Wayne F. Tackabury wrote:
>Started with:  access-list 5 deny 192.33.1.56
>               access-list 5 permit any
>
>New config was: access-list 5 deny 177.12.19.47
>                access-list 5 permit any
>
>The "update" config couldn't be derived from diff:
>
>                no access-list 5
>                access-list 5 deny 177.12.19.47
>                access-list 5 permit any
>
>In general, anything that requires *turning off* a prior association or clearing a construct requires an intelligent translator for most configuration formats (I could give a much much more difficult example with 802.1q VLAN activation).  This would be the challenge of the kind of built-in convertibility you propose, to somehow handle this in how it specifies absence or presence of configuration information.

The is subtle - a quality issue that can be either
the equipment vendors problem or the configuration mgmt vendors problem.

If, in order to modify something, you have to negate it in its entireity, that
can be pretty unusable operations wise especially if it causes instability in an area
greater than say a given device. (bgp soft reconfig, not dropping LSDB's when
adding a new OSPF interface, etc). The decision tends to be made by 
the engineer adding the new feature so most CLI's are not consistent 
within a given device/software version when it comes to making modifications.

But if an application just blows away rows in order to reload when the device
supports being able to do precise changes, the application may not be usable.

Mike MacFaden