Subject: Re: [netmod] mandatory mess

From: Gerhard Muenz <[email-masked]>
Date: Sun, 09 Aug 2009 00:44:48 +0200

Hi,

Reading this e-mail thread, I see a similarity to various cases in the
IPFIX configuration data model where parameters (= leaf values) are
given by the device if the user does not configure them. The idea is the
following:
- These leaves always exist if the ancestor node exists.
  (opposed to leaves whose non-existence has a specific meaning)
- The user does not have to configure them.
- There is not default value specified in the module.
- The value given by the device does not always have to be the same for
all occurrences of the leaves. It is assigned dynamically when the
ancestor node is created.
In IPFIX, these parameters have been modeled as non-mandatory leaves
(i.e., without "mandatory true;"). The behavior cannot be formalized.
Therefore, the behavior is only specified in the description.

I think that the initial device configuration this discussion is about
is very similar: Parameters, which always exist (even if not yet
configured by the user), are set by the device at startup.

However, these parameters are not mandatory, because mandatory means
that the user has to provide them when he sends a complete configuration
(e.g., with copy-config).

I'm not sure if such parameters should be returned as response to
get-config having with-defaults=false. It would be logic not to return
them because the user has not set them. On the other hand, the
parameters are definitively part of the configuration datastore because
their values may be dynamically assigned when the ancestor node is
created or at startup (not using the same value all the time).

Coming back to the YANG guidelines, I think it makes sense to discourage
mandatory/min-element!=1 objects at the toplevel. What has been
discussed in this thread are parameters that always exist and that are
designed by the device unless the user changes them. However, they are
not mandatory in the common sense.

We had this discussion in Dublin. Having "mandatory true/false" is not
sufficient to cover this "third" type of parameter. There was a proposal
of "assigned-by system;" or the like, but it did not make it into YANG
1.0. Maybe, this problem can be solved in the next YANG version.

Regards,
Gerhard

Phil Shafer wrote:
> Ladislav Lhotka writes:
>> 1. Is this factory default configuration (part of) the 'initial default
>> state' that RFC 4741 talks about?
> 
> No, I don't think so.  This is just a default config content that the
> device will supply if you don't give one.
> 
>> 2. Will the values set this way be returned in get-config having
>> with-defaults=false?
> 
> No.  You are free to delete such "factory default" config.
>
>> 3. Is it possible that this factory default configuration sets some
>> optional leafs to values that differ from the defaults specified in the
>> data model? 
> 
> Sure, I could have a default syslog file called "messages" that has
> a large value for "size" and "count" that are not the normal defaults.
> 
> Thanks,
>  Phil

---

From: Phil Shafer <[email-masked]>
Date: Sun, 9 Aug 2009 00:10:07 -0400

>Therefore, the behavior is only specified in the description.

We have a proposal for "assigned-by system", but I'm not sure what
happened to it.  The statement was meant to indicate exactly the
scenario you are in, where the value is assigned by the system
(device) if no value is given.

We have one such scenario in JUNOS (where a "uid" is automatically
assigned if none is given).

But I don't see this as being involve with the default values
discussion, since defaults are meant to be invisible, where these
"assigned-by system" leafs are automatically created and always
appear there after.

Thanks,
 Phil