Re: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt

["maqiufang (A)" <[e-mail]>]

Hi, Andy

Thanks for your feedback, please see my reply inline.

From: Andy Bierman [mailto:[e-mail]]
Sent: Friday, June 2, 2023 6:00 AM
To: Kent Watsen <[e-mail]<mailto:[e-mail]>>
Cc: Jan Lindblad (jlindbla) <[e-mail]<mailto:[e-mail]>>; Jürgen Schönwälder <[e-mail]<mailto:[e-mail]>>; Rob Wilton (rwilton) <[e-mail]<mailto:[e-mail]>>; maqiufang (A) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt



On Thu, Jun 1, 2023 at 1:55 PM Kent Watsen <[e-mail]<mailto:[e-mail]>> wrote:
Hi Quifang,

The latest update looks very good to me - IMO, ready for adoption.

Jan, Jurgen, Andy, Rob - can you confirm that your concerns have been addressed?



IMO the problem statement and solution are still rough and unclear.
The different behavior for each type of node made it even more unclear.
Could you please explain where you think is not clear enough? that would be much appreciated.
There is a useful improvement to configuration automation here, but it needs more work.
Thank you Andy, but beyond your comments below, please let us know what you think is left.
            The problem is that sometimes the server does not allow certain edits to config=true nodes.
This can cause automated (or manual) edit requests to be rejected by the server, with no way
for the client to fix the edit request.
It seems that we are in agreement! I see no conflict or inconsistency between us.
For your information, the document already states:
   Clients may use "immutable" statements in the YANG, and annotations
   provided by the server, to know beforehand when certain otherwise
   valid configuration requests will cause the server to return an
   error.
I think you problem statement is another different way to express the motivation.
The edit operations 'add', 'modify', and 'delete' need more clarification.
I am not sure which part you are referring to. but I suppose you are targeting Sec.3.
If that’s the case, I am thinking maybe we can rephrase section 3.3~section3.6 for clarity, e.g.,
Sec.3.3. the “container” statement:
OLD:
   When a container data node is immutable, its instance can neither be
   created nor removed.  Additionally, as with all interior nodes,
   immutability is recursively applied to descendants (see Section 4).
NEW:
When a container data node is immutable, its instance cannot change, unless the
descendant nodes override the inherited immutability property (see Section 4).

And explain above Sec.3.1 that “change” refers to the operations create, update, and delete.

If it is needed, maybe also explain the three operations like the following:
Create: the client adds a new data node instance to a configuration datastore
update: the client updates an existing data node instance in a configuration datastore
delete:  the client deletes a data node instance from a configuration datastore

Would this be suitable from your perspective?
There seem to be 3 usage modes that must be supported

-  The server provides the value, and the client does not provide it
-  The client provides a server-approved value that can not change
-  The client picks a value that cannot change

In the example in A.2, any of the 3 modes could apply to a client creating a new interface entry.
Could you please provide some detailed JSON or XML snippets about the example? I am not sure I’ve fully understand you all three usage modes.
Regarding the first usage mode, I assume you mean system-defined configuration, but if there is a reference to that system-provided node, it would still be needed to copy into <running>.

In all cases it seems the intent is to allow the client to create an immutable node,
but not modify it.  It can only be deleted if a mutable ancestor is being deleted.
This is something we talked about on the mailing list before, there was a big discussion about the non-transactional cases.
Configuration that cannot change once created by the client and needs to be deleted first with its ancestor node and then recreate by the client, requires a transaction to be split into two transactions, thus lost the desire to move from one valid configuration to another in a single transaction. There was some concern thus the WG decides that this is something that this draft should not support.
It is not clear how inherited immutable flag values work, especially in conjunction with NACM.
Could you please expand on this comment? To me, I think immutable flag should work independently of NACM.
YumaPro has supported the "user-write" extension for many years for this purpose.
https://docs.yumaworks.com/en/latest/yangauto/builtin-yang-extensions.html#ncx-user-write
Yes, and a lot of vendors/SDOs has defined the similar but proprietary concept, the objective is to define a standard solution for interoperability;-)
It supports all 3 usage modes above.  IMO the immutable attribute should support all 3 modes.
We do support all 3 usage modes in the previous version, but it seems that this could easily lead to non-transactional APIs, e.g., a client can create a node instance but cannot modify it afterwards.

I do not understand the purpose of the with-immutable parameter.
The client can just parse the YANG modules from the server and find the nodes with an immutable field.
The purpose is that a client can use a with-immutable parameter carried in the operation request(e.g., get-config) to ask the server to return the immutable metadata annotation, so that a client unware or not supportive of immutable metadata annotation will never receive it in the server’s response. See section 4 in RFC7952(https://datatracker.ietf.org/doc/html/rfc7952#section-4) :

“Generally, it is safe for a server to use
   annotations in the following cases:
…
 o  The client explicitly asks the server, e.g., via a parameter of a
      protocol operation request, to include an annotation in the
      response.
”

It is right that the client can parse the YANG modules to find the immutable nodes if the immutability is conveyed via the YANG extension, but there are some instance-level immutability that uses an immutable metadata annotation to communicate, e.g., only some system-defined list entries are immutable while others are not, which cannot be acquired by parsing the YANG modules. Make sense?
Thanks,
Kent



Andy

Best Regards,
Qiufang



On May 25, 2023, at 8:16 AM, maqiufang (A) <maqiufang1=[e-mail]<mailto:[e-mail]>> wrote:

Hi, all
This version reflects the input we've received from the mailing list.

Thank you everyone(Jan, Rob, Kent, Jürgen, Andy, Frank et al.) for your great comments and suggestions!
Please see if the following updates are good for you:
   *  Use a Boolean type for the immutable value in YANG extension and
      metadata annotation
   *  Define a "with-immutable" parameter and state that immutable
      metadata annotation is not included in a response unless a client
      explicitly requests them with a "with-immutable" parameter
   *  reword the abstract and related introduction section to highlight
      immutable flag is descriptive
   *  Add a new section to define immutability of interior nodes, and
      merge with "Inheritance of Immutable configuration" section
   *  Add a new section to define what the immutable flag means for each
      YANG data node
   *  Define the "immutable flag" term.
   *  Add an item in the open issues tracking: Should the "immutable"
      metadata annotation also be returned for nodes described as
      immutable in the YANG schema so that there is a single source of
      truth.

Thanks a lot.

Best Regards,
Qiufang

-----Original Message-----
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Thursday, May 25, 2023 4:52 PM
To: Balazs Lengyel <[e-mail]<mailto:[e-mail]>>; Hongwei Li <[e-mail]<mailto:[e-mail]>>; Qin Wu <[e-mail]<mailto:[e-mail]>>; Qin Wu <[e-mail]<mailto:[e-mail]>>; maqiufang (A) <[e-mail]<mailto:[e-mail]>>
Subject: New Version Notification for draft-ma-netmod-immutable-flag-07.txt


A new version of I-D, draft-ma-netmod-immutable-flag-07.txt
has been successfully submitted by Qiufang Ma and posted to the IETF repository.

Name:                  draft-ma-netmod-immutable-flag
Revision:              07
Title:                      YANG Extension and Metadata Annotation for Immutable Flag
Document date:               2023-05-25
Group:                  Individual Submission
Pages:                   24
URL:            https://www.ietf.org/archive/id/draft-ma-netmod-immutable-flag-07.txt
Status:         https://datatracker.ietf.org/doc/draft-ma-netmod-immutable-flag/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ma-netmod-immutable-flag
Diff:           https://author-tools.ietf.org/iddiff?url2=draft-ma-netmod-immutable-flag-07

Abstract:
   This document defines a way to formally document existing behavior,
   implemented by servers in production, on the immutability of some
   configuration nodes, using a YANG "extension" and a YANG metadata
   annotation, both called "immutable", which are collectively used to
   flag which data nodes are immutable.

   Clients may use "immutable" statements in the YANG, and annotations
   provided by the server, to know beforehand when certain otherwise
   valid configuration requests will cause the server to return an
   error.

   The immutable flag is descriptive, documenting existing behavior, not
   proscriptive, dictating server behavior.




The IETF Secretariat



_______________________________________________
netmod mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netmod