Hi, Andy Thanks for your feedback, please see my reply inline.
From: Andy Bierman [mailto:[email protected]] Sent: Friday, June 2, 2023 6:00 AM To: Kent Watsen <[email protected]<mailto:[email protected]>> Cc: Jan Lindblad (jlindbla) <[email protected]<mailto:[email protected]>>; Jürgen Schönwälder <[email protected]<mailto:[email protected]>>; Rob Wilton (rwilton) <[email protected]<mailto:[email protected]>>; maqiufang (A) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:kent%[email protected]>> 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) <[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> [mailto:[email protected]] Sent: Thursday, May 25, 2023 4:52 PM To: Balazs Lengyel <[email protected]<mailto:[email protected]>>; Hongwei Li <[email protected]<mailto:[email protected]>>; Qin Wu <[email protected]<mailto:[email protected]>>; Qin Wu <[email protected]<mailto:[email protected]>>; maqiufang (A) <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
