Hi Med, One comment. See inline.
> On Jun 22, 2026, at 2:16 AM, Mohamed Boucadair via Datatracker > <[email protected]> wrote: > > 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. One problem with citing these external SDOs by name is what you cite below. We do not want to create an impression that this somehow addresses their ask, which you note we do not, below. > > # 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”? I do not think the draft is claiming that their requirements are being fulfilled by this draft. All it is acknowledging is that that vendors and organizations can use what this draft is standardized the solution as. Cheers. > > # 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 > > > Mahesh Jethanandani [email protected]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
