Gunter, RFC4252 was cited on purpose as this is an example of mandatory ** secure ** transport layer. This is consistent with RFC 6242, which has the following:
To run NETCONF over SSH, the SSH client will first establish an SSH transport connection using the SSH transport protocol, and the SSH client and SSH server will exchange keys for message integrity and encryption. The SSH client will then invoke the "ssh-userauth" service to authenticate the user, as described in the SSH authentication protocol [RFC4252<https://datatracker.ietf.org/doc/html/rfc4252>]. Once the user has been successfully authenticated, the SSH client will invoke the "ssh-connection" service, also known as the SSH connection protocol. Hope this helps. Cheers, Med De : Gunter van de Velde (Nokia) <[email protected]> Envoyé : mercredi 24 juin 2026 14:21 À : maqiufang (A) <[email protected]>; Mahesh Jethanandani <[email protected]>; BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : The IESG <[email protected]>; [email protected]; Kent Watsen <[email protected]>; [email protected]; [email protected] Objet : Re: [iesg] Gunter Van de Velde's Discuss on draft-ietf-netmod-immutable-flag-13: (with DISCUSS and COMMENT) Hi Qiufang, Your proposed edits look fine to me. Many thanks. About my 3 DISCUSS's: [DISCUSS#1] The context and explanation from Mahesh helps to understand how this textual in-accuracy was inherited from RFC9907. Knowing this aspect, I agree that it is not fair to keep your document hostage (=blocked) with a DISCUSS because the in-accuracy is in an inherited text from another document that normatively mandates to use the not-accurate text. I'll clear the discuss after understanding how OPS-ADS @Mahesh Jethanandani<mailto:[email protected]> @Mohamed Boucadair<mailto:[email protected]> intend to structurally resolve the in-accuracy that slipped into RFC9907. The correct SSH transport RFC should of been RFC 4253 (The Secure Shell (SSH) Transport Layer Protocol) and not RFC 4252 (The Secure Shell (SSH) Authentication Protocol). If this does not get changed, then more and more drafts with a YANG module will end up having an incorrect reference. [DISCUSS#2] resolved and DISCUSS#2 considered closed [DISCUSS#3] resolved and DISCUSS#3 considered closed I'll update my ballot and keep only [DISCUSS#1] open until learning how OPS-ADs will structurally avoid this inaccuracy happening in the future. G/ ________________________________ From: maqiufang (A) <[email protected]<mailto:[email protected]>> Sent: Wednesday, June 24, 2026 10:37 AM To: Mahesh Jethanandani <[email protected]<mailto:[email protected]>>; Gunter van de Velde (Nokia) <[email protected]<mailto:[email protected]>> Cc: The IESG <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; Kent Watsen <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: RE: [iesg] Gunter Van de Velde's Discuss on draft-ietf-netmod-immutable-flag-13: (with DISCUSS and COMMENT) You don't often get email from [email protected]<mailto:[email protected]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hi, Gunter, Mahesh, and all, Thanks Gunter for the detailed review. In addition to the clarifications provided by Mahesh and Med, the authors have prepared a PR to address your remaining DISCUSS and comments: https://github.com/netmod-wg/immutable-flag/pull/33/changes. For some of your comments below, please also see my reply below inline with [Qiufang]… From: Mahesh Jethanandani [mailto:[email protected]] Sent: Wednesday, June 24, 2026 3:32 AM To: Gunter Van de Velde <[email protected]<mailto:[email protected]>> Cc: The IESG <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; Kent Watsen <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [iesg] 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. [Qiufang] Agree with Mahesh here. I believe any such enhancements or corrections to the security text should first be addressed and reflected in the template itself. At this time, the authors prefer to maintain alignment with the current security consideration templates in 9907. [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. [Qiufang] Good comment. Have fixed this in the PR by explicitly incorporating the proper error-tag: If it has any unexpected value, then a “400 Bad Request” status-line MUST be returned by the server. The error-tag value “invalid-value” is used in this case. [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."; " [Qiufang] The description statement has been updated as suggested. Thanks. ---------------------------------------------------------------------- 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. [Qiufang] In line with YANG 1.1 specification (RFC 7950), I think that the term "ignore" is well-understood by implementers and inherently means that the server will not reject the request. Introducing terms like “silently” might be redundant. Thus the authors prefer to maintain the current concise text. 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. [Qiufang] I see your point that this behavior has some subtlety. But the foundational rules are already normatively defined in the referenced section given at the end of the sentence. Adding a repetitive reminder might introduce unnecessary redundancy. Agreed? 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. [Qiufang] As clarified by Med, I confirm that this should remain RFC 6020. Kind Regards, Gunter Van de Velde Routing Area Director Best regards, Qiufang//co-author 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]
