Hi Qiufang Thanks for the follow-up and changes made in -13. This looks great.
One quick comment on this one: > 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." I have noted that. My comment was actually hoping that you include some text to explain what we gain operationally from this vs. using the 8040 behavior ;-) One nit in -13: OLD: immutable-annotation" module Section 9 by reading the YANG library NEW: immutable-annotation" module (Section 9) by reading the YANG library Cheers, Med > -----Message d'origine----- > De : maqiufang (A) <[email protected]> > Envoyé : mardi 23 juin 2026 10:49 > À : BOUCADAIR Mohamed INNOV/NET <[email protected]>; > The IESG <[email protected]> > Cc : [email protected]; > [email protected]; [email protected]; [email protected] > Objet : RE: Mohamed Boucadair's Yes on draft-ietf-netmod- > immutable-flag-12: (with COMMENT) > > > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > author-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod- > immutable-flag- > 13&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C74d8954f770d433 > 55dd408ded10451a0%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639 > 178013638714070%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl > YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D > %7C0%7C%7C%7C&sdata=hSEDwW56BmXZG94pknMWHawYQ9KPTB7FM%2BcSpdpRPZQ% > 3D&reserved=0. 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.) > > ------------------------------------------------------------------ > 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > github.com%2Fnetmod-wg%2Fimmutable- > flag%2Fpull%2F27%2Fchanges&data=05%7C02%7Cmohamed.boucadair%40oran > ge.com%7C74d8954f770d43355dd408ded10451a0%7C90c7a20af34b40bfbc48b9 > 253b6f5d20%7C0%7C0%7C639178013638787150%7CUnknown%7CTWFpbGZsb3d8ey > JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=D%2BI%2Fzgeevdy8xQtjnn > cD0a%2FZUgm26PSdgOiRA6YRij0%3D&reserved=0. > [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 > > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
