Initial value

[BalazsLengyel]

3GPP is starting to use YANG for modeling. The "default value" as defined by 3GPP is actually an initial value. When the containing container/list-entry is created the leafs/leaf-lists are set to a starting value. However this value can be deleted, in which case the leaf/leaf-list is undefined (not-present). The initial value is only used at creating the containing parent.

They want to, they need to keep using this modeling concept.

I propose to introduce a Yang language concept or ietf-extension called initial value

It should have an effect when the parent is actually created in a operation independent whether a create, merge or replace, operation is used as long as the container/list entry did not exist before and exist at the end of operation.

If we don't do this 3GPP will still do it in some form.

[rgwilton]

I think that the behaviour that 3GPP is asking for is unsound from a language/architecture perspective: (1) I think that it is much cleaner/simpler to just embed the default values/behaviour into the data model. (2) Magically injecting configuration into \<running> makes it hard to know who actually owns the configuration - is it the client, or is it the server?

There are workarounds, particularly the one that Juergen described in Prague:

• When the config is added, you have a separate config client that spots the container/list-entry being created and injects the extra default configuration. The NMDA architecture allows this, although personally, I don't think that it is a great choice (due to reason 2 above).
• Another alternative could be to defined a separate RPC in the data model that creates the list/container configuration along with the default entries.

[BalazsLengyel]

This behavior of initial values has been used by 3GPP for cca. 15 years, so there is very little chance of changing it now. We can either support it, or say that they should implement their own yang extension statement. IMHO 3GPP (including all the 5G networks) is important enough for IETF to provide support.

It is important to provide these initial values in the same transaction, as validation may depend on them, in a similar way as on defaults. This rules out using separate actions/rpcs for setting the initial values.

Generally I believe the idea that configuration in running is ONLY modified by explicit management operations is too restrictive. Even our current RFCs allow both the system and rpcs/actions to update running. Automation may also inject items into running not just into operational. If you wanted to remove these possibilities I would ned to fight that or violate the standard.

[rgwilton]

I would suggest that it would be better for the system to inject configuration between and , along the lines of a default config template for the device. This way the input from the client isn't being modified by the system.

[BalazsLengyel]

I don't fully understand what you mean by default-config-template for a device.

3GPP defines these initial-values per attribute (leaf/leaf-list) in its standard docs (technical specifications). The initial values are not device specific, but model/attribute specific and must follow the 3gpp standard. So the YANG formal definition should also be on a leaf/leaf-list level.

A device may implement some specific collection of this3gpp models (classes), while there are some rules about selecting these models/classes, but there are many allowed subsets of these classes that a device may or may not implement.

The classes and attributes will be mapped into a YANG models, lists, leafs, leaf-lists, but what to do with the initial values. We should document them formally: how does the system modify configuration based on the the standard initial-values, hence the need for the new YANG statement or extension..

[rgwilton]

My previous suggestion doesn't work.

I think that the 3GPP approach is a different way of handling defaults that doesn't immediately seem to be compatible with YANG. I currently would be opposed to standardizing this within the IETF because I think that it makes it very ambiguous over who is the "source of truth" the configuration for a device, it is a client, or is it the device - I think that it should always be the client.

Is seems that with the 3GPP approach, after any config change, a client is required to read back and merge it back in with its config generation systems, check whether the configuration is what it desired, delete the defaults if those are not wanted, and then push it back down to the device again.

The 3GPP approach also means that the behavior is potentially different after a device has restarted. I.e. there is some extra meta-state that must be maintained by the device to know whether or not to auto-create an initial value (which might or might not be what the client wants). This doesn't obviously seem like great behaviour.

I think that the best, but perhaps unrealistic, outcome would be to convince the 3GPP folks that the 3GPP approach is not a good way of modelling configuration defaults in YANG due to the issues that it introduces.

Alternatively, if this is done as a YANG extension to define an initial value, then I would recommend also adding a protocol option (and capability) to NETCONF's and to indicate that initial values should be instantiated as part of the request, at least giving control back to the client. But I still don't think that this should be part of the base YANG/protocol standards because it seems to introduce unnecessary extra complexity.

[abierman]

Is this overtaken by the immutable annotation?

they should use an extension like 'initial-value' instead of defining a YANG default Seems to ignore YANG rules that say a missing leaf that has a default-stmt MUST use that value.

[abierman]

agree with Balazs that servers need to inject config data sometimes. This is a different issue than initial-value.

       leaf foo {
           type int32;
           initial-value 10;
       }

Propose syntax update so either initial-value or default-value is present, but not both.

     [default-stmt / initial-value-stmt]

Support add: complexity=medium bc=high importance=medium

[QiufangMa]

Is this overtaken by the immutable annotation?

No, I understand it as a deletable system config case. If there is an initial value that could be specified beforehand, it provides more predictability of servers. Support.

[kwatsen]

I was also thinking this was more like the system-config case than the immutable-flag case. That said, I don't understand how the system-config solution supports initial values for, e.g., list entries...maybe via system-defined templates?

Nit: above it was stated that rpcs/actions can update . I do not believe this is true, since rpc/action use for their context. Note: I'm aware that RFC8342, Section 6.2 says an RPC might be defined to modify the contents of some datastore., but I've never seen this done or proposed, and I would be dubious of any intention for an rpc/action to update .

[janlindblad]

Happy to discuss this new concept, but I must say it does sound very tricky to define in an interoperable way. When is an "object" created, i.e. initial-values apply to children, and when is it merely updated, i.e. defaults apply? There is no "object" concept in YANG.

[BalazsLengyel]

I did not ask for "objects". Initial value shall be set when its parent container/list is created. We do have containers/lists :-)

[kwatsen]

Rob: this could be a long discussion wrt what this means.

Rob: is this an initial or suggested value Balazs: a set value, i.e., config

Rob: question is if this is sane? Balazs: has worked for 20 years.

[abierman]

I think I get Rob's point.

The operational differences between a default and an initial value need some explanation.

The issue is why does this leaf only apply to the model during initialization and not after the client explicitly deletes it?

Seems to make sense for interoperability. Maybe some objects are needed to get system components setup to communicate, and they will not be relevant after this setup is completed.

This is different than purely optional, like a zipcode leaf in an address. The zipcode is always either in the address or not in the address. There is no 'starting' zipcode.