Hi, Rob, Thanks a lot for your comments, much appreciated. The authors tried to incorporate them into a new revision which will be posted when the submission window reopens, and the diff is available at: https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-netmod-immutable-flag&url_2=https://netmod-wg.github.io/immutable-flag/draft-ietf-netmod-immutable-flag.txt
Please also find my response below inline. From: Rob Wilton (rwilton) [mailto:rwil...@cisco.com] Sent: Wednesday, March 12, 2025 1:27 AM To: Kent Watsen <kent+i...@watsen.net>; netmod@ietf.org; draft-ietf-netmod-immutable-f...@ietf.org Subject: Re: [netmod] 1st WGLC on immutable-flag Hi Kent, authors, NETMOD, Here are my WGLC comments on draft-ietf-netmod-immutable-flag-02. Thank you to the authors persevering with topic. I'm not totally convinced that we need this document but I can appreciate that the authors (and other SDOs) believe that this work is important and helpful, and I can also appreciate that reporting this is one common way is better than bespoke vendor extensions. As such, and as written I think that it does no harm, hence I'm not opposed to the WG publishing this .... All being said, I have a few comments: Moderate level comments: (1) p 7, sec 5.1. The "leaf" Statement When a leaf node instance is immutable, its value cannot change. Surely, you can also not delete a leaf that is marked as immutable, otherwise, it would be possible to change its value simply by deleting it, then creating it with a new different value? The same comment also applies to leaf-lists. Yes, I agree with you. Immutable configuration can only be provided by the system, and there is no way for a client to delete a system-provided node. The client may simply remove the immutable node from <running> (which won't prevent the node from appearing in <intended>) but it won't be possible for the client to create a new different value. But I don't feel there is any extra statement that we need to say, as we already mentioned in sec.5 that "Throughout this section, the word 'change' refers to create, update, and delete". Given this, is there any text that you would like propose to be added here? (2) p 7, sec 5.3. The "container" Statement When a container node instance is immutable, it cannot change, unless the immutability of its descendant node is toggled. Do you mean descendant node here, or ancestor node? Why would the immutability of a child node affect its parent node? The same comment applies to list statements. I think it should be descendant node. I can see your confusion, I guess that is because we failed to make it clear in the draft what it means to change a container. If a container is immutable, any of its child nodes should not be added, modified, or deleted. Any changes to a child node would cause the container node to change as well, unless a child node toggles its immutability explicitly. Would the following update work for you? OLD: When a container node instance is immutable, it cannot change, unless the immutability of its descendant node is toggled. NEW: When a container node instance is immutable, it cannot change (i.e., any descendant node instances and the presence for "presence container" cannot change), unless the immutability of its descendant node is toggled. (3) p 7, sec 5.4. The "list" Statement When a list node instance is immutable, it cannot change, unless the immutability of its descendant node is toggled. RFC 7952 does not allow meta-data annotations to list's themselves, only to list entries. This probably needs to be clarified that lists (and leaf-lists) can only inherit immutability from a parent node. But even a list inherits immutability from a parent node, this makes no difference from every single instance being annotated as immutable. We have the following statement in the draft: "If a list inherits immutability from an ancestor (e.g., container), it is identical to each individual list entry being annotated without any bearing on the entry ordering and addition of new entries." Given this, do we still need any more clarification? (4) p 11, sec 9. YANG Module feature immutable { description "Indicates that the server supports the 'immutable' metadata annotation."; } Is this feature required? What does it mean if this module is implemented by the server but this feature isn't implemented? You are right, a client can simply discover this implementation by reading YANG-library and see if this module is implemented by the server. We've gotten rid of the feature in the proposed update. (5) p 12, sec 10. Security Considerations The security considerations for the Defining and Using Metadata with YANG (see Section 9 of [RFC7952]) apply to the metadata annotation defined in this document. Note that RFC's security considerations section states: This document introduces a mechanism for defining metadata annotations in YANG modules and attaching them to instances of YANG data nodes. By itself, this mechanism represents no security threat. Security implications of a particular annotation defined using this mechanism MUST be duly considered and documented in the annotation's definition. This probably means that you may need a bit more text in this document to state that knowing whether or not a data node is immutable does not give any significant additional information to an attacker. Agree. The following being added in the security considerations: "The immutable metadata annotation exposes the immutability of configuration data, which may provide hints for attackers to find vulnerabilities in the network, e.g., to leverage the immutability of some configuration to better craft an attack. Since immutable annotations are attached to the instances of configuration data nodes, it is only accessible to clients that have the permissions to read the annotated configuration nodes." Better? Minor level comments: (6) p 3, sec 1. Introduction * UC4 Declaring immutable system configuration from an LNE's perspective LNE isn't defined anywhere. Presumably Logical Network Element? Fixed by changing this as: UC4 Declaring immutable system configuration from the perspective of a logical network element (LNE) (7) p 5, sec 3. Applicability While immutable flag applies to all configuration nodes, its value "true" can only be used for system configuration. 'system configuration' should probably be defined and reference the system-datastore draft or NMDA draft. Added this "system configuration" terminology in sec.2. Conventions and Definitions. (8) p 5, sec 3. Applicability The immutable flag is also visible in read-only datastores like <system> (if implemented, see [I-D.ietf-netmod-system-config]), <intended> and <operational> when a "with-immutable" parameter is carried (Section 4.2), however this only serves as descriptive information about the instance node itself, but has no effect on the handling of the read-only datastore. This states that the immutable flat is also visible in read-only datastores, but presumably it is only visible in read-only datastores, since everything in <running>, is by definition, under the clients control and writable, or can be deleted? Immutable configuration won't be present in <running> by default (it can only be created by system). But it is still possible for a client to copy an immutable node into <running> and then fails to override its value, in this case, do you think it has some merit for <running> to return immutable flag as well? Another benefit for <running> returning immutable flag is for the consideration of non-nmda servers, where it won't have a system ds, but some implementation returns the system configuration via a get operation. Thoughts? (9) p 5, sec 3. Applicability An instance has the same immutability if it appears in different writable datastores, the immutability of data object is also protocol and user independent. The immutability and configured value of an existing node MUST only change via software upgrade, hardware resources change, or license change. I think that this second sentence isn't really clear. Is the following what is meant, and would this be more clear? The immutability of any configuration data node, and the value of any immutable configured data node, MUST only change via software upgrade, hardware sources change, or license change. Yes, your proposal is clearer, thanks a lot. I've incorporated it into the update. (10) p 5, sec 4.2. "with-immutable" Parameter This section specifies the NETCONF [RFC6241] and RESTCONF [RFC8040] protocol extensions to support the "with-immutable" parameter. The "immutable" metadata annotations are not returned in a response unless explicitly requested by the client using this parameter. Possibly consider naming the flag: "with-immutability", "with-immutability-flag", "with-immutability-annotation" This would make it more consistent with "with-defaults" Agree consistence would be good, fixed with "with-immutability". (11) p 9, sec 9. YANG Module <CODE BEGINS> file ietf-immuta...@2024-06-04.yang<mailto:ietf-immuta...@2024-06-04.yang> module ietf-immutable { Maybe consider calling this module "ietf-immutable-annotation" or "ietf-immutability-flag". Fixed with "ietf-immutable-annotation", thanks. Kind regards, Rob Thanks again! Best Regards, Qiufang
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
