Allow some references to from config-true to config-false (add capabilities)

[BalazsLengyel]

IN some cases it would be needed to allow referencing config=false data from config=true leafrefs.

E.g. if the capabilities of the server are listed in a model as config=false values I want a leafref with require-instance=true to reference them. If I have a leaf-list of allowed timer values, and have to configure a job dependent on that timer, I want to restrict the job to choose one of the allowed timer values.

[schoenw]

Restricting value spaces has been brought up before, I am not sure this should be resolved by allowing config true to reference config false data. If you configure a value that is not in the current set of values reported in , then the config is still valid I think. Validity of config must not depend on data in .

[rgwilton]

I see that there are two competing requirements here:

1. Configuration must always be valid, and can never become invalid due to a change in operational state.
2. The configuration allowed on the device may depend on the hardware inserted, software licensing and other potentially dynamically changing data.

One possible solution to this problem is to introduce a second phase on validation (e.g. on ) that occurs independently and after the current validation. This second phase of validation is: "Is it expected that this configuration change will be applied successfully?". This second phase of validation would be allowed to depend on current values in operational, and would not be guaranteed to always be valid.

A second possible solution for this problem is to define the capabilities as config true, with the system normally injecting the configuration between \<running> and \<intended>. E.g. a bit like implicit template expansion.

A third possible solution for this problem would be define capability data as something that is neither config nor operational state, but something else entirely.

I do agree with Balazs that there is a problem to be solved here, although I would rather see this as an independent ID rather than trying to directly put it into the next version of YANG.

[mbj4668]

I also agree that something like this could be useful, for things that are "permanent" but modelled as config false. But I haven't seen an acceptable solution proposal to this issue yet.

[BalazsLengyel]

What we do in Ericsson is an extension:

extension static-data {
    description "Indicates that a data node contains data that is
        loaded by the system at system start and is only changed during
        system start and cannot be created/deleted/changed through
           Netconf, Restconf or CLI.

        The data MAY be marked as config true to allow leafref,
        when or must constraints to be based on it.

        When changing static-data backward compatibility
        MUST be considered. The following changes are considered
        backwards incompatible:
        - If a data node indicates support for a subfunction, changing
        it to remove support
        - Decreasing the valuespace of a whitelist (e.g. supported values)
        - Increasing the value space of a blacklist (e.g. prohibited values)

        The statement MUST only be a substatement of the leaf, leaf-list,
        container, list, anydata, anyxml statements.
        Zero or one static-data statement per parent statement is allowed.
        NO substatements are allowed.

        The argument is a boolean value indicating whether the data node
        is considered static-data or not. If static-data is not specified,
        the default is the same as the parent data node's value. For top
        level data nodes the default value is false.

[llhotka]

This is related to #58.

[llhotka]

@rgwilton I agree with your analysis. I think the best solution would be to put such read-only data that are mostly permanent on a given server to a special datastore. In fact, YANG library data also has this character.

[BalazsLengyel]

We need this for non-NMDA nodes too.

Also I see this as a property of data. I don't think using a separate datastore would be the best way to characterize a specific data node.

Also in some cases real changeable configuration data and this kind of static capability data is mixed inside a list. Seeing them only separately in 2 different datastores is awkward.

[BalazsLengyel]

Closed by mistake

[kwatsen]

This issue may be addressed, in part, by defining an "immutable" annotation that could generically identify "config true" nodes as effectively read-only.

Such an annotation could also be used when nodes become read-only due to, e.g., access-control or being in a virtual-machine context.

The difference between this and Balazs's proposal is that this approach can be more dynamic, e.g., varying by the client's access-control.

[BalazsLengyel]

The problem with access control is that the user (CLI-Netconf-Restconf) can modify access control e.g. insert an allow-everything rule in the first position, thereby removing any protection provided by ACM. In the capabilities use-case we do not want ANY operator to be able to remove the immutability. At least for this use-case we want immutability to be rather static.

So how would you protect against an operator changing access control? How dynamic would your solution would be?

---

One idea (that I am not sure about) was to designate some access control rules as immutable themselves. E.g. if the rule-group's name starts with "_system" it can only be changed by the system itself.

[kwatsen]

This issue seems to be solved by the system-config and immutable-flag drafts - almost published