Hi,
I went through the doc, have not reviewed it extensively but +1 to this comment
from Balazs. I don't see the use-case for supporting this per instance either.
If we make this a schema property it can be documented in a transparent manner
with a YANG extension statement. If it is handled as instance connected metadata
the client cannot know a-priori whether a data node is or is not immutable.
This information
is only available in runtime. System integrators, OSS developers will have a
problem.
Regards,Reshad.
On Wednesday, March 23, 2022, 03:23:32 PM EDT, Balázs Lengyel
<balazs.lengyel=40ericsson....@dmarc.ietf.org> wrote:
Hello,
I did a review of the immutable draft. My comments questions are below.
Regards Balazs
General)
I think this work is important and valuable, but it needs quite a lot
improvements.
Why is immutable connected to instances. IMO it should be a schema property.
If we connect it to instances it is hard/impossible to specify “it is
prohibited to create a
new container, list entry of leaf-list value”. That is clearly needed for the
capability-check use-case. Maybe allow it on both schema and instance ?
If we make this a schema property it can be documented in a transparent manner
with a YANG extension statement. If it is handled as instance connected metadata
the client cannot know a-priori whether a data node is or is not immutable.
This information
is only available in runtime. System integrators, OSS developers will have a
problem.
As immutability is connected to instance (now) this raises the question how
stable this property is?
- We don't say anything; the server can keep it stable or make the data node
immutable every odd second and writable every even second
- The property should be relatively stable in an unspecified manner
- The property shall be set when the data node is created and the property
should not change till the data node is deleted/replaced
- Can the immutable property be set on just some interfaces e.g. the
leaf is readOnly on the CLI but writable on Netconf ?
If we make immutable a schema-property, the problem will not arise.
IMO it would be important to list the use-cases we want to solve. I provide 3
below.
Ch 1)
I don't like paragraph 2. Someone could say just declare the interface name
config=false which is a quite usual solution.
I would rather change the first and second paragraphs to:
"YANG [RFC7950] is a data modeling language used to model both state
and configuration data, based on the "config" statement. However there is data
that should not be modifiable by the client, but still needs to be declared
as config true. Some examples of this problem are presented below:
Interfaces are represented as list entries. The list schema node must be
defined as config=true as many of its child leaves need to be configurable by
the client. However the interface name and type values are set by the system,
based on the hardware actually present in the device, and must not be modified
by clients. The natural solution would be to declare the name (which is the
list's key) and the type as config=false. However according to the rules of
YANG the key leaf for a configuration list must also be config=true. Thus the
leaf /interfaces/interface/name is config true even if it might not be
writable in some systems.
System capabilities might be represented as system-set data nodes in the model.
Configurable data nodes might need constraints specified as "when", "must" or
"path" statements to ensure that configuration is set according to the system's
capabilities. E.g.,
- a timer can support the values 1,5,8 seconds. This is defined in the
leaf-list ‘supported-timer-values’.
- When the configurable ‘interface-timer’ leaf is set it should be ensured that
one of the supported values is used. The natural solution would be to make the
‘interface-timer’ a leaf-ref pointing at the ‘supported-timer-values’.
However, this is not possible as ‘supported-timer-values’ must be readOnly thus
config=false while ‘interface-timer’ must be writable thus config=true.
According to the rules of YANG it is not allowed to put a constraint between
config true and false schema nodes.
If configuration is created by the system (e.g., copied from the <system>
datastore to the <running> datastore it might need to be protected. In some
cases there is a need to ensure that system-originated configuration shall
not be altered even after it is copied over to the <running> datastore.”
Ch 2)
"Create an immutable data node with a same value initially set by
the system if it doesn't exist in the datastore, e.g., explicitly
configure a system generated interface name in <running>;"
IMO this is not needed because
- If the data already exists in the <running> datastore it cannot be
created according to Netconf rules.
- If it does not exist in the <running> datastore there is nothing that could
be immutable as immutable is linked to the instances.
The above is independent of what is defined in <system>
Until now we never
had any constraints between 2 datastores like:
you can update datastore1 if datastore2 contains something.
I don't think we want to introduce that either.
"Comment: Should we allow the client delete an "immutable" system
instantiated node in <running> ?"
Once a data node is instantiated there is no record where it came from.
https://datatracker.ietf.org/doc/html/rfc8342#section-5.3.4 states that origin
is only maintained in the <operations> datastore. Unless we want to introduce
it into <running>. So the even the question is wrong as we don't know which
data is system instantiated.
Servers MUST reject any attempt to the "create", "delete" and
"update" access operations on an immutable data node "
Create cannot be handled. see comment on chapter 2.
Ch2 last paragraph) Edit-config is not allowed towards the startup datastore
so it shouldn't be mentioned here. Why wait with error reporting for candidate.
Is there any chance that the immutability might change?
A.2) Interesting example, but it would not work because the use may always
insert a rule(-list) before the immutable rule(s) that will make the imuutable
rules ineffective. The problem is that the rule(-sets) are a user ordered list
where the order matters. It is not enough to protect the individual rule(sets)
the order would also need protection.
IMHO it would be much easier and just as useful to define an extension
statement:
extension immutable {
description
"Indicates that a data node contains data that is
loaded by the system and cannot be created/deleted/changed through the
Netconf, Restconf or other management interfaces like SNMP, CLI.
The data MAY be marked as config true to allow leafref,
when or must constraints to be based on it.
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.
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.
When the effective immutable value is true, the ‘description’ statement
of
the parent statement SHOULD contain the text 'This data node (tree)
cannot be changed in a running system.' ";
argument value;
}
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
