Re: [YANG] mandatory & default

Balazs Lengyel wrote:
> Hello,
> I agree with Andy that a leaf either exists or not. I don't like half 
> existing defaults.
> Please also consider that defaults effect much more then just the 
> get-config results. (See attachment.
> I attached a file about an alternative (and I hope very understandable) 
> solution. Please start to tell me why it is bad :-)
> Balazs
> 
> PS.Sorry if my proposal is long.
> 

Here is just a snippet to discuss:

Yang statements:
- mandatory: means it must be present in the datastore if the parent exists
- initial-value: Will be used at creation of the parent if no value for
the leaf is specified. Anything that was created with an initial value
will really exist in the configuration. Later it does not matter if it
was created explicitly or with an initial value.
- default-value: means if the leaf does not exist, the server will use
this value internally, but the leaf really does not exist. Can not be
used with mandatory. "Must" statements consider the leaf not-existing but
we introduce a special hasDefault() function. Or alternatively as a
CLR "must" considers the leaf existing.)

------

IMO, this 'default-value' is unacceptable.
A manager application may need to retrieve all the nodes that
exist in the database.  Requiring complex analysis of multiple
external documents to determine the value of some of the nodes
seems like a huge burden on application developers.

How does the manager application know for sure whether
an implementation actually supports a node or not?

If some nodes are inaccessible under all conditions, but they
really exist with some value, then how can a manager application
know for sure if the agent really is using the specified default?

If the value of the default changes over time, or varies between
products or vendors, then how can a manager application know
for sure what exact version of the default value is being used by the agent?

I know of many operator horror stories in years past, caused by silent,
undocumented default value changes between releases, and different code
bases across product platforms.  A full diff of the config files
before and after the upgrade would have instantly revealed the
source of the problem, but of course, since nobody needs to
see these CLI defaults, that was not an option.

Assumption is the mother of all foul-ups, to paraphrase the B movie...

Andy

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