Hi, Jan Thanks for supporting this work! Please see inline. From: Jan Lindblad (jlindbla) [mailto:[email protected]] Sent: Friday, June 2, 2023 10:23 PM To: Kent Watsen <[email protected]<mailto:[email protected]>>; maqiufang (A) <[email protected]<mailto:[email protected]>> Cc: Jürgen Schönwälder <[email protected]<mailto:[email protected]>>; Andy Bierman <[email protected]<mailto:[email protected]>>; Rob Wilton (rwilton) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [netmod] New Version Notification for draft-ma-netmod-immutable-flag-07.txt
Kent, Quifang, I support adoption of this work. It is an architecturally deep and important topic. I think a good amount of work remains before we reach consensus, and that it is important to get the details just right since this is going deep towards the roots of our vision. Glad to know that;-) I have some detailed comments below, but nothing that affects the adoption call. On 1 Jun 2023, at 22:55, Kent Watsen <[email protected]<mailto:[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? Thanks, Kent Quifang, Thank you for the updated draft. I think each version is getting better :-) but I still have some comments. Sure. + Section 1, Introduction Immutability is an existing model handling practice. While in some cases it is needed, it also has disadvantages, therefore it MUST be avoided wherever possible. While I strongly agree with the view stated here, I don't think we can have a MUST requirement on something so nebulous as "whenever possible". Change to SHOULD? Happy to change to SHOULD. + Section 1.2, Applicability The immutability of data nodes is protocol and user independent. I agree fully that the immutability concept should be protocol and user independent (i.e. works the same for both NC/RC/xC and all users). I would also like to add that immutability needs to be independent of operational state, i.e. that immutable nodes are immutable from time of creation and remain so for as long as they exist. Thank you Jan for pointing this out. But I am unsure if the “operational state” here has the same meaning as in NMDA spec. My understanding is that you would like to mention immutability is unchanged in the node instance’s lifecycle, I think I agree with you. Do you think would it be okay to add the following sentence: “It is also independent of the lifecycle of a node from time of creation to deletion.” The immutability property and configured value of an existing node must only change by software update. Sure, but would the configured value of an immutable node also changes by other conditions like license or hardware capability/resource changes? + Section 2, Solution overview However, the following operations SHOULD be allowed for immutable nodes: * Use a create, update, delete/remove operation on an immutable node if the effective change is null. E.g., if a leaf has a current value of "5" it should be allowed to replace it with a value of "5" * Create an immutable data node with a same value that already exists in <operational> or <system> (if exists) in order to e.g., configure a mutable descendant or reference it in a "when", "must" or "leafref" expression. * Delete an immutable data node from read-write configuration datastores (i.e., <running>, <startup> and <candidate>) which do not prevent the data node still appearing in <operational> or <system> (if exists) By the already established rules of 7950, I think the above statements are already MUST requirements. It may be good to clarify/restate that expectation here, but if so, I find it essential not to weaken the requirement to SHOULD (in the first cited line above) , but keep it MUST. Okay, but it is not the intention to weaken the rules in the existing RFCs. Do you have any suggestions to rephrase these above statements? + Section 6.1, Definition Note that "immutable" metadata annotation is used to annotate data node instances. A list may have multiple entries/instances in the data tree, "immutable" can annotate some of the instances as read- only, while others are read-write. I think the immutable annotation on individual instances is useful, meaning those list instances would always have to be present. This is however getting very close to the edge for some of the deep no-nos for me. Let's say there is a management interface that always has to exist for the configuration to be valid. Annotating that with immutable seems ok. But if someone suggests that some of these must-exist list elements can vary over time, i.e. sometimes have to exist, sometimes not, then I'm out. Not supportive. Let’s state in the document that “the existence of immutable node instances cannot change unless software update, license or hardware capability/resource changes”, thoughts? Basically, I don't want to ever get into a situation where I have a backup from time t that is not valid at some later time t+1. Noted. + Section A.5, UC5 - Immutable BGP peer type list neighbor { key "remote-address"; leaf remote-address { type inet:ip-address; description "The remote IP address of this entry's BGP peer."; } leaf peer-type { im:immutable; type enumeration { enum ebgp { description "External (EBGP) peer."; } enum ibgp { description "Internal (IBGP) peer."; } } mandatory true; description "Specify the type of peering session associated with this neighbor. The value can be IBGP or EBGP."; } In my opinion, this use case is taking the immutability concept too far. It creates more problems than it solves. A configuration that was valid at time t may no longer be valid at time t+1. Someone may argue that this use case is similar to UC2 in section A.2, which is an interface list with the interface type being immutable. I think UC2 is ok if the set of immutable list nodes is constant as long as the hardware capabilities and software version remains the same. With UC5, the dependency is towards an external system that could basically change at any time. I don't want immutable nodes to appear, disappear or change value unless we're doing something drastic like installing new hardware or software. I understand your point and tend to agree with you, I think it probably should be removed from the document. Best Regards, /jan 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
