Hi Gunter, all, Exactly what Mahesh said.
The same reasoning applies for this comment as well: > Section 10.2 / IANA YANG Module Names registry reference > > The IANA text references RFC 6020 for the YANG Module Names > registry. This is > conventional, but since the module is YANG 1.1 and the document > otherwise uses > RFC 7950, please check whether the registry reference should > remain RFC 6020 or > be updated/augmented with RFC 7950/RFC 9907 guidance. Th document correctly follows the template at https://datatracker.ietf.org/doc/html/rfc9907#name-iana-template-for-documents The reason is that RFC7950 points to RFC6020 for such matters: XML namespaces for modules published in RFC streams [RFC4844<https://datatracker.ietf.org/doc/html/rfc4844>] MUST be assigned by IANA; see Section 14 in [RFC6020]<https://datatracker.ietf.org/doc/html/rfc6020#section-14>. and Names of submodules published in RFC streams [RFC4844<https://datatracker.ietf.org/doc/html/rfc4844>] MUST be assigned by IANA; see Section 14 in [RFC6020]<https://datatracker.ietf.org/doc/html/rfc6020#section-14>. Hope this helps. Cheers, Med De : Mahesh Jethanandani <[email protected]> Envoyé : mardi 23 juin 2026 21:32 À : Gunter Van de Velde <[email protected]> Cc : The IESG <[email protected]>; [email protected]; Kent Watsen <[email protected]>; [email protected]; [email protected] Objet : [iesg] Re: Gunter Van de Velde's Discuss on draft-ietf-netmod-immutable-flag-13: (with DISCUSS and COMMENT) Hi Gunter, Just one comment on one of your DISCUSS points. Please see inline. On Jun 23, 2026, at 8:22 AM, Gunter Van de Velde via Datatracker <[email protected]<mailto:[email protected]>> wrote: Gunter Van de Velde has entered the following ballot position for draft-ietf-netmod-immutable-flag-13: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Authors, WG, # Gunter Van de Velde, RTG AD, comments for draft-ietf-netmod-immutable-flag-13.txt # line numbers are rendered from the idnits tool found at https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netmod-immutable-flag-13.txt # When reviewing this document, i observed 3 blocking DISCUSS items i would like to have more discussion about and a series of non-blocking COMMENTS to help streamline the document accuracy. [DISCUSS#1] Section 12 / Security Considerations: secure transport references and requirements The security text says that NETCONF/RESTCONF “have to use a secure transport layer”, giving SSH, TLS, and QUIC examples. However, SSH is cited as RFC 4252, which is the SSH authentication protocol, not the SSH transport protocol. Please either cite the correct SSH transport / NETCONF-over-SSH references, or rely on the base NETCONF/RESTCONF security references. 658 RESTCONF [RFC8040]. These YANG-based management protocols (1) have 659 to use a secure transport layer (e.g., Secure Shell (SSH) [RFC4252], 660 TLS [I-D.ietf-tls-rfc8446bis], and QUIC [RFC9000]) and (2) have to 661 use mutual authentication. Consider using normative MUST statement, instead of 'have to use'. Is transport security optional? You will notice that the Security Considerations section starts by saying that "This section is modeled after the template described in Section 3.7.1 of [RFC9907].” That is a guidance provided for all documents that are defining a YANG module. The two paragraphs you cite are from the template in RFC 9907. In some sense, it is more a question for RFC 9907 than this document per se. Having said that, since this is Security Considerations section, the emphasis is on the SSH Authentication capability than the transport. RFC4252 states in the Abstract that "The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol.” HTH. [DISCUSS#2] Section 4.2.2 / RESTCONF error behavior The text says that if “with-immutability” has an unexpected value, RESTCONF returns “400 Bad Request”. Please also specify the RESTCONF error-tag / error-app-tag behavior, or explain why HTTP status alone is sufficient. This is especially useful because Section 3 specifies “unknown-element” for invalid datastore usage, while Section 4.2.2 only specifies the HTTP status code. [DISCUSS#3] Section 9 / YANG module: when expression on with-immutability The with-immutability leaf is conditional on the datastore being system, intended, or operational. Please confirm that this gives the intended NETCONF error behavior when the leaf is supplied for another datastore. Section 3 says the server MUST return unknown-element; it would help to make the relationship between the YANG when constraint and that required error explicit. Proposal to change the description: 591 description 592 "If this parameter is present, the server returns the 593 'immutable' annotation for configuration that it considers 594 immutable."; Proposed: " "Requests that immutable metadata annotations be returned. This parameter is only valid when the datastore is operational, intended, or system. See [this document] Section 3 for the required error behavior when used with other datastores."; " ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- COMMENTS Abstract / terminology The abstract says “not proscriptive, dictating server behaviors.” I think “prescriptive” is intended, not “proscriptive”. Section 1 / error-tag wording The text says the server is expected to return “an error with an error-tag containing invalid-value”. “containing” is unusual here. Suggest “with error-tag value invalid-value”. Section 2 / definitions The definition of “immutable flag” says it is a “read-only state value”. Since the document is careful to distinguish operational state, configuration, and system configuration, “state value” may be confusing. Consider “server-provided metadata value” or similar. Section 3 / applicability The text says the immutable flag applies to all configuration nodes, but MUST NOT be set to true for configuration data that is not system configuration. This is an important limitation. Please consider saying this earlier in the Introduction as well, because it constrains the intended use of the annotation. Section 4.1 / descriptive versus behavioral semantics The document says the flag is descriptive and does not regulate server behavior, but also says that immutable nodes cannot be changed or deleted from intended. That is mostly clear in context, but the language sometimes reads as normative behavior definition. It would help to consistently frame this as “a node marked immutable indicates that the server will not allow...” rather than as a new rule imposed by this document. Section 4.1 / client-supplied annotations “Servers MUST ignore any immutable annotations sent from the client.” Please consider adding whether this applies to all edit operations and encodings, and whether ignoring means silently ignoring rather than rejecting. Section 4.2.2 / RESTCONF capability registry The RESTCONF capability URI is defined, but the text should be explicit about the server advertising it in the RESTCONF capability leaf-list. This follows the RFC 8040 optional query parameter model. Sections 5.1 and 5.2 / “configured with a different value” For leaf-list entries, “configured with a different value” is slightly odd because changing a leaf-list entry is normally remove/add, not modify-in-place. Suggest using add/remove/reorder terminology consistently for leaf-list entries. Sections 5.3–5.6 / create/delete wording Several sections say immutable containers/lists/anydata/anyxml cannot be removed from intended, “though it can be created/deleted in read-write configuration datastores”. This is subtle and likely to confuse readers. Please consider adding a short reminder that such client-created/deleted nodes do not alter the server-provided value in system/intended. Section 6 / inheritance “The immutability of top hierarchy of returned nodes is false by default” is awkward. Suggest “For each top-level returned node, the default immutable value is false unless explicitly annotated.” Section 7 / system datastore interaction The text says immutable configuration is present in system “if implemented” but also says immutability is independent of whether system is implemented. This is important and could use one concrete example for servers that do not implement the system datastore but still return immutable annotations in intended/operational. Section 10.2 / IANA YANG Module Names registry reference The IANA text references RFC 6020 for the YANG Module Names registry. This is conventional, but since the module is YANG 1.1 and the document otherwise uses RFC 7950, please check whether the registry reference should remain RFC 6020 or be updated/augmented with RFC 7950/RFC 9907 guidance. Kind Regards, Gunter Van de Velde Routing Area Director Mahesh Jethanandani [email protected]<mailto:[email protected]> ____________________________________________________________________________________________________________ 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]
