Re: [netmod] Review of draft-ma-netmod-immutable-flag-00

[Reshad Rahman <[e-mail]>]

 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=[e-mail]> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/netmod