Hi, Med, Thanks a lot for the careful review, the authors have published -13 to address your comments below. The diff is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-immutable-flag-13. Please also see my reply below inline...
-----Original Message----- From: Mohamed Boucadair via Datatracker [mailto:[email protected]] Sent: Monday, June 22, 2026 5:16 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Mohamed Boucadair's Yes on draft-ietf-netmod-immutable-flag-12: (with COMMENT) Mohamed Boucadair has entered the following ballot position for draft-ietf-netmod-immutable-flag-12: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi Qiufang, Qin, Balázs, and Hongwei, Thank you for the effort put into this specification. Please find below some few comments. A PR that fix some nits can also be found here: https://github.com/netmod-wg/immutable-flag/pull/27/changes. [Qiufang] Thanks a lot. I have merged this PR with some fix, e.g., typos. # Other SDOs CURRENT: This document defines a YANG metadata annotation [RFC7952] to formally document an existing model handling behavior that has been used by multiple standard organizations and vendors. Can we please cite at least 3GPP and ONF here. [Qiufang] Done. # Single Standard CURRENT: It is the aim to create one single standard solution for documenting non-modifiable system data declared as configuration, instead of the multiple existing vendor and organization specific solutions. Is this still accurate given that the approach here does not meet the full needs expressed by some of the “other SDOs”? [Qiufang] This is a fair point. I have removed this sentence. # Incomplete Placeholder CURRENT: Please apply the following replacements: * XXXX --> the assigned RFC number for this draft * 2026-05-26 --> the actual date of the publication of this document Please add YYYY to refer to system configuration I-D. Also, note that the date used in the example module does not match the one listed here. [Qiufang] Fixed. # Invalid datastore CURRENT: If the immutable flag is requested to be returned for an invalid datastore, then the server MUST return an error response with the error-tag value "unknown-element". Maybe better to indicate what is an “invalid datastore” here: a datastore other than system/intended/operational. [Qiufang] Fixed. # Check behavior CURRENT: This document extends Sections 4.8 and 9.1.1 of [RFC8040] to add a query parameter named "with-immutability" to the GET operation. and "ietf-restconf:errors": { "error": [ { "error-type": "application", "error-tag": "invalid-value", "error-severity": "error", "error-path": "/example-user-group:user-groups/group[name='\ administrator']/access-level", "error-message": "Invalid access-level value because the \ target node is marked as immutable" } ] } Given that the new query parameter is not expected for a PATCH method, the following behavior should be followed per 8040: o A server MUST return an error with a "400 Bad Request" status-line if a query parameter is unexpected. The error-tag value "invalid-value" is returned in this case. Why the error message is diving into more granular error handling while the parameter is not allowed at the first place for that method? [Qiufang] Note that this error message is caused because the client attempts to override an immutable node, rather than an unexpected query parameter for a PATCH method. The two examples in B.6 are symmetrical following the below sentence in introduction section: "That said, it is expected that a server will return an error with an error-tag containing "invalid-value" if a client attempts to modify an immutable node." # Please follow the template for IETF module in RFC 9907 [Qiufang] Fixed. # Only if implemented CURRENT: description "If this parameter is present, the server returns the 'immutable' annotation for configuration that it considers immutable."; Shouldn’t the description indicate that this is only of the server implements this query parameter? [Qiufang] I am unsure this is needed. If the YANG module is declared to be supported by the server, it inherently implies implementation of this parameter. I think this is redundant by explicitly adding "if the server implements this" in the YANG model context. Also if we look at the description of leaf with-origin in RFC 8526, it says "If this parameter is present, the server will return the 'origin' annotation for the nodes that have one."; Note one of the objectives of this document is try to be consistent with what has been defined for with-origin/origin metadata annotation. # Missing Operational Considerations Section I would expect that at least we mention backward-compatibility considerations. Any considerations about how this can be used to drive intended configuration by clients? [Qiufang] Yes, this is what we have missed. Please review this section in -13. And feel free to let us know if you have further comments. # Please follow the template for registering YANG modules as defined in 9907 [Qiufang] Fixed. # Missing details CURRENT: * When the configurable 'interface-timer' leaf is set, it should be ensured that one of the supported values is used. The natural solution would be to make the 'interface-timer' a leaf-ref pointing at the 'supported-timer-values'. Difficult to follow the example as 'interface-timer' was not introduced earlier. Some assumptions are missing here. [Qiufang]Have added some explanation and background text. Hopefully this helps. # Add a reference for these rules CURRENT: According to the rules of YANG it is not allowed to put a constraint between "config true" and "config false" data nodes. [Qiufang] done. # Inappropriate use of normative language in an example OLD: * The type cannot be marked "config false", because we MAY need to reference the type to make different configuration nodes conditionally available. NEW: * The type cannot be marked "config false", because we may need to reference the type to make different configuration nodes conditionally available. [Qiufang] Fixed. # Applicable if the parameter is supported by the server CURRENT: Figure 2 illustrates a NETCONF request example to retrieve "user- groups" configuration in <system> with "with-immutability" parameter and the response a server might return. NEW: Figure 2 illustrates a NETCONF request example to retrieve "user- groups" configuration in <system> with "with-immutability" parameter and the response that a server might return if it supports this query parameter. [Qiufang] Fixed. # Add RFC 8792 as an informative reference CURRENT: =============== NOTE: '\' line wrapping per RFC 8792 ================ [Qiufang] fixed. # Remind that JSON representation of annotation is done per RFC7952 [Qiufang] fixed. CURRENT: Figure 3 illustrates a RESTCONF request example to retrieve "user- groups" configuration in <system> with "with-immutability" query parameter and the response a server might return. For illustrative clarity, some annotations that could otherwise be omitted are shown explicitly in the response. # I don’t parse the following sentences CURRENT: Other descendant nodes inside "administrator" list entry inherit the immutability of the list entry thus are also immutable. .. Other descendant nodes inside "power-users" group inherit the immutability of the list entry thus are also mutable. [Qiufang] Have listed the examples of descendant nodes that inherit the immutability and fixed the improper grammatical flow. let us know if you still see it unclear. Cheers, Med Best regards, Qiufang //co-author _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
