Re: [YANG] mandatory & default

Juergen Schoenwaelder píše v Po 28. 01. 2008 v 11:41 +0100:
> On Mon, Jan 28, 2008 at 11:10:12AM +0100, Ladislav Lhotka wrote:
> > 
> > Juergen Schoenwaelder p????e v Po 28. 01. 2008 v 10:47 +0100:
> > 
> > > 
> > > My point is you need to be able to (a) get all configuration settings
> > > of a box and (b) the subset that was explicitely configured. It is
> > > then the operator's choice what to use where and when. Trying to rule
> > > out (a) over (b) or (b) over (a) is wasting time and bandwidth.
> > 
> > I don't intend to rule anything out, I just don't wan't to have (b) as a
> > mandatory function in all devices. It should be an optional capability.
> > On the other hand, (a) is by all means essential.
> 
> Our problem is that others believe (b) is by all means essential and
> (a) should be an optional capability. This is our dilemma.
> 
> Why is it not OK to have (a) and (b)? Why do you not want to have (b)
> as a mandatory function in all devices? Do you think it is too costly
> to maintain this additional bit per explicitely configured knob or are
> there other reasons?

I guess it is probably because two different implementations are around:

1. The device has an internal "database" of operational parameters
(perhaps as registers, variables and structures in its firmware and
software) but its configuration is something else, for example only the
stuff that the user specified. For this implementation it is an extra
burden to retrieve the parameters from the operational structures and
write them to the configuration.

2. The operational values are explicitly represented in a configuration
database and the internal operational values are either taken directly
from it or synchronised with it (e.g., via ioctl for firmware). This
implementation can simply dump the entire database while it is an extra
burden to keep the information about whether a parameter has been
changed or not.

I understand that JUNOS, IOS and some Unix daemons like GateD use 1
while we use 2 in our devices, but it doesn't matter. The question
really is: Is it OK if we allow a device to keep part of the essential
operational parameters for itself? If the answer is NO, then
implementation 1 must be able to do the homework and collect all the
values for the manager. So, for me (a) is a necessity.

On the other hand, approach 2 doesn't hide anything, it only poses
technical difficulties to the manager by sending the entire operational
configuration. However, I claim it is possible to protect the human user
from being overwhelmed by other means outside the device, i.e., (b) is
not a necessity.

Lada

> 
> /js
> 
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

_______________________________________________
YANG mailing list
YANG@ietf.org
https://www1.ietf.org/mailman/listinfo/yang