RE: FW: FW: RFC3535 question/clarification

[Andy Bierman <abierman@cisco.com>]

At 12:25 PM 9/15/2003, Glenn Waters wrote:

>Andy wrote: 
>
>> There has been an additional requirement raised that I don't 
>> agree with -- the ability to indicate that a parameter has ever 
>> been set by management, even if the value is the same as the 
>> default value.  This is not the same as suppression of defaults, 
>> which is a bad idea.  This is a 'dirty bit' flag that is true 
>> if the object has ever been set by management action.  I don't 
>> see the value of knowing that the operator explicitly set the 
>> knob to 10, or implicitly set it to 10 via a default. 
>
>The requirement was to know which attributes of the configuration were touched by a management action so that a get-config would only return the attributes that were actually set by a management action. The purpose being to:

I don't remember this requirement at all.


>- Help make the configuration returned by the device the same as the configuration sent to the device;

A get-config operation should return the entire requested configuration,
regardless of which operator set the value.  Hiding changes from other
operators could prevent conflicts from being detected.

> 
>
>- Reduce the size of the configuration information returned by a device (some devices have very large amounts of default configuration);

There are ways to subset the data returned in a get-config response.
Note that the issue I raised is not default suppression.  The maintenance
of a dirty bit for every parameter is an unreasonable burden.
Suppression of default values is not that hard to do.  It can cause
problems if the application makes assumptions about default values
that are incorrect.


>- Allow the network operator to continue to use the device's default values for attributes after a retrieved configuration is sent back to the box (once the default value becomes a part of a configuration file then it becomes difficult to edit the configuration file and it is also difficult to pickup new default values that the device may implement).

First you are arguing for default suppression, now you are pointing
out why it's a bad idea to use it.


>A corner case is when a management action sets the value of an attribute to the attribute's default value. The above three points still apply.

This is the case for the 'dirty bit' that I am arguing against.


>So, this is a very real requirement. The WG needs to decide if they want to support this requirement. 

There any several issues mixed together here.  They need to be
separated and then justified.   


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