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

[[e-mail]]

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 <[e-mail]>
Envoyé : mardi 23 juin 2026 21:32
À : Gunter Van de Velde <[e-mail]>
Cc : The IESG <[e-mail]>; [e-mail]; Kent Watsen <[e-mail]>; [e-mail]; [e-mail]
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 <[e-mail]<mailto:[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]<mailto:[e-mail]>





____________________________________________________________________________________________________________
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.