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. # 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. # 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”? # 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. # 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. # 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? # Please follow the template for IETF module in RFC 9907 # 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? # 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? # Please follow the template for registering YANG modules as defined in 9907 # 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. # 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. # 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. # 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. # Add RFC 8792 as an informative reference CURRENT: =============== NOTE: '\' line wrapping per RFC 8792 ================ # Remind that JSON representation of annotation is done per RFC7952 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. Cheers, Med _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
