[netmod] Re: [iesg] Gunter Van de Velde's Discuss on draft-ietf-netmod-immutable-flag-13: (with DISCUSS and COMMENT)

[Mahesh Jethanandani <[e-mail]>]

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 <[e-mail]> 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
[e-mail]