Hi Qiufang, Please find some responses below.
Kent > On Feb 26, 2026, at 3:29 PM, maqiufang (A) > <[email protected]> wrote: > > 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] > <mailto:[email protected]> > Cc: [email protected] <mailto:[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? Unsure. I understand what you're saying, but still wonder what it means for new system nodes that are not one of the three scenarios mentioned. That is, if <system> changes (A) are a superset of immutable-flag changes (B), what can be said about (A-B)? To be clear, this draft only discusses the intersection (A^B). PS: I assume the (B-A) is empty - yes? I appreciate Jan's concern, as we only want to surprise clients under very controlled scenarios. But shouldn't that concern apply to all of <system>? Should draft-ietf-netmod-system-config-20#section-6.1 be a MUST instead of a MAY? [PS: system-config is out of the WG now, so we need to decide carefully] > 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? Maybe, I guess the question is, is this text (and elsewhere, on a case by case basis) referring to the term or to the flag called "immutable"? If using the term, then I agree that no quotes are needed. > 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. True, if fact, YANG Library SHOULD be used in both cases. And for the NETCONF case, could one claim that there should be a capability in the <hello> message? More generally, my point is that 4.2.2 speaks about discovery, while 4.2.1 doesn't mention it at all. 4.2.1 could have a sentence like "clients discover server support via yang library and the <hello> message." I hope that NETCONF-next and RESTCONF-next will eliminate the duplicate <hello> and RESTCONF-capabilities, solely relying on YANG-library. > 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” > (seehttps://datatracker.ietf.org/doc/html/rfc8527#section-3.2.1) and > “with-origin” > (seehttps://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? I'm glad for the research. Yes, there's precedent this document needs to mimic. If we agree that the long-term solution is to only depend on YANG-library for such things, then it seems that documents in the interim should mention the yang library option first, as the primary discovery option, and the legacy discovery option second, just to "check the box". > 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 Kent // Shepherd
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
