Hi, Kent, Thanks a lot for the review, I've submitted -08 to address your comments. Please also see my reply below inline...
From: Kent Watsen [mailto:[email protected]] Sent: Wednesday, February 18, 2026 8:49 AM To: [email protected] Cc: [email protected] Subject: Shepherding immutable-flag Dear Authors, In doing the Shepherd writeup, I found some issues. Thanks, Kent (in document order) 1) nit: s/internally thinks immutable/internally thinks the data is immutable/ Fixed. 2) For the paragraph: "This document does not apply to the server not having any immutable system configuration. While in some cases immutability may be needed, it also has disadvantages, therefore it SHOULD be avoided wherever possible." a) the first sentence contains a double-negative. Would "This document only applies to servers having system configuration." ? b) what are the "disadvantages"? c) I question if this paragraph is needed at all. Have removed this whole paragraph. 3) Section 1.1: s/input parameter/query parameter/ Fixed. 4) This is a nit, but Section 3 says: "its value "true" can only be used for system configuration". Technically, the value "true" is encoding-dependent. Whilst true for both XML and JSON, I imagine CBOR uses a binary value. Note, the use of "true" and "false" in Section 9 is okay, since it is a NETCONF/XML-specific If changing here, also consider changing the first sentence in Section 3 (Applicability). In all cases, I think the fix is just to remove the quotes around the true/false strings. Make sense, have removed the quotes in Section 3. 5) Section 3 also says: "An instance has the same immutability if it appears in different datastores, the immutability of configuration data is also protocol and user independent." a) this looks like two sentences. b) assuming the 1st sentence is "An instance has the same immutability if it appears in different datastores", I don't understand if needed (since it's more a "system-config" statement) but, if keeping, then maybe s/instance/instance data/ or s/instance/configuration data/ ??? c) assuming the 2nd sentence is "the immutability of configuration data is also protocol and user independent.", the word "also" can be removed. Okay, fixed. 6) Section 3 also says: "The immutability of any configuration data, and the value of any immutable configured data node, MUST only change via software upgrade, hardware resources change, or license change." But https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-20#section-6.1 says "The contents of <system> MAY change dynamically under various conditions, such as license change, software upgrade, and system-controlled resources change (see Section 2.2)." There seems to be a mismatch. Since the first paragraph in Section 3 says "While immutable flag applies to all configuration nodes, its value "true" can only be used for system configuration.", maybe this sentence can be removed, deferring to the "system-config" draft to define when system-config can change? I think there are some subtle differences between the two. Changes to <system> cover a broader scope (e.g., including mutable system configuration appear/disappear/have their values update), while the change of immutability of system config and its value are only subsets of such cases. So it might be okay if we restrict the triggers for such immutability-related changes to these specific scenarios. This also aligns with the WG discussion, where several folks (most notably Jan Lindblad, if I remember correctly) highlights that servers should strictly constrain changes to immutable nodes to some very specific and exhaustive cases. As reflected in the minutes of the February 2024 interim (see https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-02-202402061400/): Can a server: 1) change/create/delete an immutable element? 2) change an element from immutable true to immutable false or vice-versa? Answer: yes, but only in very specific scenarios that will be defined in the document (as an exhaustive list of the only allowable scenarios), e.g.: software update of the server licensing changes of the server hardware changes Would it be okay if we just keep this sentence as it is? 7) In Section 4.1: OLD: The immutable flag which is defined as the metadata annotation takes a boolean value NEW: The "immutable" flag, which is defined as a metadata annotation, takes a boolean value The term immutable flag is used consistently throughout the draft, are you suggesting this update be applied all in the draft? Also note that the term "immutable flag" is formally defined in Section 2: immutable flag: A read-only state value the server provides to describe immutability of the configuration, which is conveyed via a YANG metadata annotation called "immutable" with a boolean value. Based on this, I feel that quotation might not be necessary. Agreed? 8) Section 4.2.2 says: "To enable a RESTCONF client to discover if the "with-immutability" query parameter is supported by the server, the following capability URI is defined: urn:ietf:params:restconf:capability:with-immutability:1.0". Shouldn't there be a similar statement in Section 4.2.1? Section 4.2.1 refers to NETCONF extension, but I think yang library should be used to discover if a NETCONF server supports this flag. So I don't really think an extra capability URI is needed for NETCONF. But then why the YANG library way cannot be used equally for RESTCONF protocol? for RESTCONF, I think it would be good to be consistent with the definition of "with-defaults" (see https://datatracker.ietf.org/doc/html/rfc8527#section-3.2.1) and "with-origin" (see https://datatracker.ietf.org/doc/html/rfc8527#section-3.2.2) query parameter. A RESTCONF server implementing the yang module (searching YANG library) indicates that it supports the get-data RPC operation with the flag; while the flag defined as the query parameter is added to the GET method, so I don't feel they are the same. Note 8527 does require the usage of the YANG library, but it also defines the query parameter and related capability URI for "with-defaults" and "with-origin" parameters. Make sense? 9) In Section 6: s/for returned child node/for a returned child node/ Fixed. 10) In Section 7: OLD: which merely mean making immutable nodes visible/invisible in the datastore. NEW: which merely makes immutable nodes visible/invisible in the datastore. or maybe something different, like "Configuring immutable nodes is generally unnecessary, but can be helpful for visibility reasons. The only time an immutable node must be configured is when it is a "key" node to a list element." ??? Have used the NEW text. Thanks. 13) In Section A1: s/config=false/"config false"/ and s/config=true/"config true"/ (as these are YANG statements) Agree, fixed. 14) In Section A2: s/config true/"config true"/ Fixed. 15) In Appendix B, s/prefix "ex-urp"/prefix ex-urp/. Found by testing the file "example-user-group.yang": ``` $ pyang -f yang --keep-comments --yang-line-length 69 example-user-group.yang > tmp && diff example-user-group.yang tmp && rm tmp 4c4 < prefix "ex-urp"; --- > prefix ex-urp; ``` Fixed. Note that I have also fix the errors PYANG reported when using "pyang --ietf" for validation. Kent // as Shepherd Best Regards, Qiufang
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
