Andy, I am not arguing for anything. I am trying to explain the discussion that was had around mid-day on Tuesday last week. I believe it was Kevin White who first raised the topic. Furthermore, during the interim the group in the room decided that a capability could be added to support this feature.
More comments inline...
> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> Sent: Monday, September 15, 2003 15:36
> To: Waters, Glenn [CAR:IO47:EXCH]
> Cc: netconf@ops.ietf.org
> Subject: RE: FW: FW: RFC3535 question/clarification
>
> 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.
This is not hiding a change. A change occurs when an attribute is set through a management action. An attribute is never set when the device supplied default value is used.
> >- 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.
The dirty bit is certainly a likely implementation for this requirement however it has nothing to do with if this is really a requirement. It may have lots to do with whether the WG wishes to consider this requirement.
> >- 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.
Huh? The point is that once a configuration file contains a pile of attributes that the user never put into the file then it is hard to get rid of them. The fact that this pile of attributes happen to match the default values on the box means that if the box default value changes then your configuration file now MUST change in order to continue to use the box's default value for an attribute. It also means that editing a configuration file that was retrieved from a box is difficult since you don't know what things someone actually configured versus what things are default values that the box put in for you.
>
>
> >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
Regards, /gww