Hi, Per, Thanks a lot for the review. -07 is posted to address your comments below, you may want to review the diff at https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-immutable-flag-07. Please also find my response below inline to some of your comments...
Best Regards, Qiufang -----Original Message----- From: Per Andersson via Datatracker [mailto:[email protected]] Sent: Tuesday, January 6, 2026 12:27 AM To: [email protected] Cc: [email protected]; [email protected] Subject: draft-ietf-netmod-immutable-flag-06 early Yangdoctors review Document: draft-ietf-netmod-immutable-flag Title: YANG Metadata Annotation for Immutable Flag Reviewer: Per Andersson Review result: Ready with Issues Hi This is my YANG-Doctor Early review of draft-ietf-netmod-immutable-flag-06. This draft one standard YANG module and one example YANG module. They booth seem to be in good shape but still have a few issues and nits. Result: Ready with Issues Summary: This document defines a way to describe immutable nodes in YANG datastores and a mechanism for clients to retrieve which nodes are immutable. General document comments: References RFCs 6241 and 8526 for NETCONF but only RFC 8040 for RESTCONF, which is good for normative references. Suggest to add RFC 8527 as a normative reference for RESTCONF since it refines (states to disregard) RFC 8040 Section 3.5.4 Default Handling for NMDA. Please give an example of how the "with-immutability" query parameter is encoded in a RESTCONF URI. I looked for how empty leafs are encoded in a URI but couldn't find anything. I assume that your intention is something like GET /restconf/data/ex-urp:user-groups?with-immutability is "...?with-immutability=" also ok? [Qiufang] RESTCONF spec may not explicitly provide the example to carry the query parameter without a value, but since RESTCONF is based on HTTP, which allows a query parameter in a URL without a value, using the format such as ?param. Appendix B.2 gives an example of this. Appendix A.4 could be expanded by also including the request supplied to the server for the output shown. Suggest one for NETCONF and one for RESTCONF (could clear the point above). Section 4.2.2 -> s/404 Bad Request/400 Bad Request/ I urge the authors to include examples for errors, e.g. when configuration changes are supplied but rejected by the server. YANG module comments: ietf-immutable-annotation: The YANG module validates with pyang --ietf and yanglint. Add reference statement for RFC 7952 to the ietf-yang-metadata import. The YANG module doesn't seem to import any definitions from RFC 6241, remove this reference in the YANG module preamble in section 9. Add references used in the YANG module in the preamble text in Section 9, i.e. add RFCs 7952, 8342, and draft-ietf-netmod-system-config (or use RFC YYYY). Use the correct RFC-to-be placeholder, i.e. change RFC HHHH and rfcHHHH to RFC XXXX and rfcXXXX respectively in the description. example-user-group: The YANG module validates with pyang and yanglint. The leaf "access-right" is probably better named "access-level". Suggest the following name changes for consistency and readability in the example: * list user-group -> group * leaf user/user-name -> user/name Nits: s/proscriptive/prescriptive/ [Qiufang] This is intentional, as the text is to emphasize that immutable flag serves a descriptive purpose, documenting existing behavior, rather than imposing restrictions or dictating server behaviors. s/doument/document/ s/ip-address/IP address/ s/these leaves/these leafs/ -- Per _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
