From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <40B4FA67-BDB5-455B-A7F6-F408B2353A03@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_727B7837-4339-4CDD-91B7-6F55F5DC6041"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
Date: Tue, 23 Jun 2026 12:31:47 -0700
In-Reply-To: 
 <178222815347.1383063.16713986942243708831@dt-datatracker-f9b87776f-8pmmg>
To: Gunter Van de Velde <gunter.van_de_velde@nokia.com>
References: 
 <178222815347.1383063.16713986942243708831@dt-datatracker-f9b87776f-8pmmg>
Message-ID-Hash: FV5DXKCDBRX5JBQYYUBDKZ6RYEAI3YEP
CC: The IESG <iesg@ietf.org>, draft-ietf-netmod-immutable-flag@ietf.org,
 Kent Watsen <kent+ietf@watsen.net>, netmod-chairs@ietf.org, netmod@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bnetmod=5D_Re=3A_=5Biesg=5D_Gunter_Van_de_Velde=27s_Discuss_on_d?=
 =?utf-8?q?raft-ietf-netmod-immutable-flag-13=3A_=28with_DISCUSS_and_COMMENT?=
 =?utf-8?q?=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/netmod/49fEsteJEXe9583s-o-cfzZLtbA>


--Apple-Mail=_727B7837-4339-4CDD-91B7-6F55F5DC6041
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Gunter,

Just one comment on one of your DISCUSS points. Please see inline.

> On Jun 23, 2026, at 8:22=E2=80=AFAM, Gunter Van de Velde via =
Datatracker <noreply@ietf.org> wrote:
>=20
> Gunter Van de Velde has entered the following ballot position for
> draft-ietf-netmod-immutable-flag-13: Discuss
>=20
> 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.)
>=20
>=20
> Please refer to =
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-position=
s/=20
> for more information about how to handle DISCUSS and COMMENT =
positions.
>=20
>=20
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/
>=20
>=20
>=20
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>=20
> Hi Authors, WG,
>=20
> # Gunter Van de Velde, RTG AD, comments for
> draft-ietf-netmod-immutable-flag-13.txt
>=20
> # line numbers are rendered from the idnits tool found at
> =
https://author-tools.ietf.org/api/idnits?url=3Dhttps://www.ietf.org/archiv=
e/id/draft-ietf-netmod-immutable-flag-13.txt
>=20
> # 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.
>=20
> [DISCUSS#1]
> Section 12 / Security Considerations: secure transport references and
> requirements
>=20
> The security text says that NETCONF/RESTCONF =E2=80=9Chave to use a =
secure transport
> layer=E2=80=9D, 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.
>=20
> 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.
>=20
> 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].=E2=80=9D 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.=E2=80=9D

HTH.

>=20
> [DISCUSS#2]
> Section 4.2.2 / RESTCONF error behavior
>=20
> The text says that if =E2=80=9Cwith-immutability=E2=80=9D has an =
unexpected value, RESTCONF
> returns =E2=80=9C400 Bad Request=E2=80=9D. 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 =E2=80=9Cunknown-element=E2=
=80=9D for invalid
> datastore usage, while Section 4.2.2 only specifies the HTTP status =
code.
>=20
> [DISCUSS#3]
> Section 9 / YANG module: when expression on with-immutability
>=20
> 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.
>=20
> 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.";
>=20
> Proposed:
> "
>  "Requests that immutable metadata annotations
>   be returned.
>=20
>   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.";
> "
>=20
>=20
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
> COMMENTS
>=20
> Abstract / terminology
>=20
> The abstract says =E2=80=9Cnot proscriptive, dictating server =
behaviors.=E2=80=9D I think
> =E2=80=9Cprescriptive=E2=80=9D is intended, not =E2=80=9Cproscriptive=E2=
=80=9D.
>=20
> Section 1 / error-tag wording
>=20
> The text says the server is expected to return =E2=80=9Can error with =
an error-tag
> containing invalid-value=E2=80=9D. =E2=80=9Ccontaining=E2=80=9D is =
unusual here. Suggest =E2=80=9Cwith
> error-tag value invalid-value=E2=80=9D.
>=20
> Section 2 / definitions
>=20
> The definition of =E2=80=9Cimmutable flag=E2=80=9D says it is a =
=E2=80=9Cread-only state value=E2=80=9D. Since
> the document is careful to distinguish operational state, =
configuration, and
> system configuration, =E2=80=9Cstate value=E2=80=9D may be confusing. =
Consider =E2=80=9Cserver-provided
> metadata value=E2=80=9D or similar.
>=20
> Section 3 / applicability
>=20
> 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.
>=20
> Section 4.1 / descriptive versus behavioral semantics
>=20
> 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 =E2=80=9Ca
> node marked immutable indicates that the server will not allow...=E2=80=9D=
 rather than
> as a new rule imposed by this document.
>=20
> Section 4.1 / client-supplied annotations
>=20
> =E2=80=9CServers MUST ignore any immutable annotations sent from the =
client.=E2=80=9D Please
> consider adding whether this applies to all edit operations and =
encodings, and
> whether ignoring means silently ignoring rather than rejecting.
>=20
> Section 4.2.2 / RESTCONF capability registry
>=20
> 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.
>=20
> Sections 5.1 and 5.2 / =E2=80=9Cconfigured with a different value=E2=80=9D=

>=20
> For leaf-list entries, =E2=80=9Cconfigured with a different value=E2=80=9D=
 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.
>=20
> Sections 5.3=E2=80=935.6 / create/delete wording
>=20
> Several sections say immutable containers/lists/anydata/anyxml cannot =
be
> removed from intended, =E2=80=9Cthough it can be created/deleted in =
read-write
> configuration datastores=E2=80=9D. 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.
>=20
> Section 6 / inheritance
>=20
> =E2=80=9CThe immutability of top hierarchy of returned nodes is false =
by default=E2=80=9D is
> awkward. Suggest =E2=80=9CFor each top-level returned node, the =
default immutable value
> is false unless explicitly annotated.=E2=80=9D
>=20
> Section 7 / system datastore interaction
>=20
> The text says immutable configuration is present in system =E2=80=9Cif =
implemented=E2=80=9D 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.
>=20
> Section 10.2 / IANA YANG Module Names registry reference
>=20
> 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.
>=20
> Kind Regards,
> Gunter Van de Velde
> Routing Area Director
>=20
>=20
>=20


Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_727B7837-4339-4CDD-91B7-6F55F5DC6041
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dutf-8"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;"><div dir=3D"auto" style=3D"overflow-wrap: =
break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi =
Gunter,<div><br></div><div>Just one comment on one of your DISCUSS =
points. Please see inline.<br =
id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote =
type=3D"cite"><div>On Jun 23, 2026, at 8:22=E2=80=AFAM, Gunter Van de =
Velde via Datatracker &lt;noreply@ietf.org&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div>Gunter Van de Velde has =
entered the following ballot position =
for<br>draft-ietf-netmod-immutable-flag-13: Discuss<br><br>When =
responding, please keep the subject line intact and reply to =
all<br>email addresses included in the To and CC lines. (Feel free to =
cut this<br>introductory paragraph, however.)<br><br><br>Please refer to =
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-position=
s/ <br>for more information about how to handle DISCUSS and COMMENT =
positions.<br><br><br>The document, along with other ballot positions, =
can be found =
here:<br>https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag=
/<br><br><br><br>---------------------------------------------------------=
-------------<br>DISCUSS:<br>---------------------------------------------=
-------------------------<br><br>Hi Authors, WG,<br><br># Gunter Van de =
Velde, RTG AD, comments =
for<br>draft-ietf-netmod-immutable-flag-13.txt<br><br># line numbers are =
rendered from the idnits tool found =
at<br>https://author-tools.ietf.org/api/idnits?url=3Dhttps://www.ietf.org/=
archive/id/draft-ietf-netmod-immutable-flag-13.txt<br><br># When =
reviewing this document, i observed 3 blocking DISCUSS items i =
would<br>like to have more discussion about and a series of non-blocking =
COMMENTS to<br>help streamline the document =
accuracy.<br><br>[DISCUSS#1]<br>Section 12 / Security Considerations: =
secure transport references and<br>requirements<br><br>The security text =
says that NETCONF/RESTCONF =E2=80=9Chave to use a secure =
transport<br>layer=E2=80=9D, giving SSH, TLS, and QUIC examples. =
However, SSH is cited as RFC 4252,<br>which is the SSH authentication =
protocol, not the SSH transport protocol.<br>Please either cite the =
correct SSH transport / NETCONF-over-SSH references, or<br>rely on the =
base NETCONF/RESTCONF security references.<br><br>658 =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RESTCONF [RFC8040]. =
&nbsp;These YANG-based management protocols (1) have<br>659 =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;to use a secure transport =
layer (e.g., Secure Shell (SSH) [RFC4252],<br>660 =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;TLS [I-D.ietf-tls-rfc8446bis], =
and QUIC [RFC9000]) and (2) have to<br>661 =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;use mutual =
authentication.<br><br>Consider using normative MUST statement, instead =
of 'have to use'. Is transport<br>security =
optional?<br></div></div></blockquote><div><br></div>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].=E2=80=9D 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.</div><div><br></div><div>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.=E2=80=9D</div><div><br></div><div>HTH.</div><div><br><blockquote=
 type=3D"cite"><div><div><br>[DISCUSS#2]<br>Section 4.2.2 / RESTCONF =
error behavior<br><br>The text says that if =E2=80=9Cwith-immutability=E2=80=
=9D has an unexpected value, RESTCONF<br>returns =E2=80=9C400 Bad =
Request=E2=80=9D. Please also specify the RESTCONF error-tag =
/<br>error-app-tag behavior, or explain why HTTP status alone is =
sufficient. This is<br>especially useful because Section 3 specifies =
=E2=80=9Cunknown-element=E2=80=9D for invalid<br>datastore usage, while =
Section 4.2.2 only specifies the HTTP status =
code.<br><br>[DISCUSS#3]<br>Section 9 / YANG module: when expression on =
with-immutability<br><br>The with-immutability leaf is conditional on =
the datastore being system,<br>intended, or operational. Please confirm =
that this gives the intended NETCONF<br>error behavior when the leaf is =
supplied for another datastore. Section 3 says<br>the server MUST return =
unknown-element; it would help to make the relationship<br>between the =
YANG when constraint and that required error explicit.<br><br>Proposal =
to change the description:<br>591 =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;description<br>592 =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;"If this parameter is present, the server returns =
the<br>593 =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;'immutable' annotation for configuration that it =
considers<br>594 =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;immutable.";<br><br>Proposed:<br>"<br> =
&nbsp;"Requests that immutable metadata annotations<br> &nbsp;&nbsp;be =
returned.<br><br> &nbsp;&nbsp;This parameter is only valid when the =
datastore<br> &nbsp;&nbsp;is operational, intended, or system. See<br> =
&nbsp;&nbsp;[this document] Section 3 for the required error behavior =
when<br> &nbsp;&nbsp;used with other =
datastores.";<br>"<br><br><br>--------------------------------------------=
--------------------------<br>COMMENT:<br>--------------------------------=
--------------------------------------<br><br>COMMENTS<br><br>Abstract / =
terminology<br><br>The abstract says =E2=80=9Cnot proscriptive, =
dictating server behaviors.=E2=80=9D I think<br>=E2=80=9Cprescriptive=E2=80=
=9D is intended, not =E2=80=9Cproscriptive=E2=80=9D.<br><br>Section 1 / =
error-tag wording<br><br>The text says the server is expected to return =
=E2=80=9Can error with an error-tag<br>containing invalid-value=E2=80=9D. =
=E2=80=9Ccontaining=E2=80=9D is unusual here. Suggest =
=E2=80=9Cwith<br>error-tag value invalid-value=E2=80=9D.<br><br>Section =
2 / definitions<br><br>The definition of =E2=80=9Cimmutable flag=E2=80=9D =
says it is a =E2=80=9Cread-only state value=E2=80=9D. Since<br>the =
document is careful to distinguish operational state, configuration, =
and<br>system configuration, =E2=80=9Cstate value=E2=80=9D may be =
confusing. Consider =E2=80=9Cserver-provided<br>metadata value=E2=80=9D =
or similar.<br><br>Section 3 / applicability<br><br>The text says the =
immutable flag applies to all configuration nodes, but MUST<br>NOT be =
set to true for configuration data that is not system =
configuration.<br>This is an important limitation. Please consider =
saying this earlier in the<br>Introduction as well, because it =
constrains the intended use of the annotation.<br><br>Section 4.1 / =
descriptive versus behavioral semantics<br><br>The document says the =
flag is descriptive and does not regulate server<br>behavior, but also =
says that immutable nodes cannot be changed or deleted from<br>intended. =
That is mostly clear in context, but the language sometimes reads =
as<br>normative behavior definition. It would help to consistently frame =
this as =E2=80=9Ca<br>node marked immutable indicates that the server =
will not allow...=E2=80=9D rather than<br>as a new rule imposed by this =
document.<br><br>Section 4.1 / client-supplied =
annotations<br><br>=E2=80=9CServers MUST ignore any immutable =
annotations sent from the client.=E2=80=9D Please<br>consider adding =
whether this applies to all edit operations and encodings, =
and<br>whether ignoring means silently ignoring rather than =
rejecting.<br><br>Section 4.2.2 / RESTCONF capability =
registry<br><br>The RESTCONF capability URI is defined, but the text =
should be explicit about<br>the server advertising it in the RESTCONF =
capability leaf-list. This follows<br>the RFC 8040 optional query =
parameter model.<br><br>Sections 5.1 and 5.2 / =E2=80=9Cconfigured with =
a different value=E2=80=9D<br><br>For leaf-list entries, =E2=80=9Cconfigur=
ed with a different value=E2=80=9D is slightly odd<br>because changing a =
leaf-list entry is normally remove/add, not modify-in-place.<br>Suggest =
using add/remove/reorder terminology consistently for leaf-list =
entries.<br><br>Sections 5.3=E2=80=935.6 / create/delete =
wording<br><br>Several sections say immutable =
containers/lists/anydata/anyxml cannot be<br>removed from intended, =
=E2=80=9Cthough it can be created/deleted in read-write<br>configuration =
datastores=E2=80=9D. This is subtle and likely to confuse readers. =
Please<br>consider adding a short reminder that such =
client-created/deleted nodes do not<br>alter the server-provided value =
in system/intended.<br><br>Section 6 / inheritance<br><br>=E2=80=9CThe =
immutability of top hierarchy of returned nodes is false by default=E2=80=9D=
 is<br>awkward. Suggest =E2=80=9CFor each top-level returned node, the =
default immutable value<br>is false unless explicitly =
annotated.=E2=80=9D<br><br>Section 7 / system datastore =
interaction<br><br>The text says immutable configuration is present in =
system =E2=80=9Cif implemented=E2=80=9D but<br>also says immutability is =
independent of whether system is implemented. This is<br>important and =
could use one concrete example for servers that do not implement<br>the =
system datastore but still return immutable annotations =
in<br>intended/operational.<br><br>Section 10.2 / IANA YANG Module Names =
registry reference<br><br>The IANA text references RFC 6020 for the YANG =
Module Names registry. This is<br>conventional, but since the module is =
YANG 1.1 and the document otherwise uses<br>RFC 7950, please check =
whether the registry reference should remain RFC 6020 or<br>be =
updated/augmented with RFC 7950/RFC 9907 guidance.<br><br>Kind =
Regards,<br>Gunter Van de Velde<br>Routing Area =
Director<br><br><br><br></div></div></blockquote></div><br><div>
<div dir=3D"auto" style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant-caps: normal; font-weight: normal; =
letter-spacing: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; text-decoration: none; caret-color: =
rgb(0, 0, 0); color: rgb(0, 0, 0); word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;"><div =
dir=3D"auto" style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); =
letter-spacing: normal; text-align: start; text-indent: 0px; =
text-transform: none; white-space: normal; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: =
break-word; -webkit-nbsp-mode: space; line-break: =
after-white-space;"><div style=3D"color: rgb(0, 0, 0); letter-spacing: =
normal; text-align: start; text-indent: 0px; text-transform: none; =
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; =
word-wrap: break-word; -webkit-nbsp-mode: space; line-break: =
after-white-space;"><div><br class=3D"Apple-interchange-newline">Mahesh =
Jethanandani</div><div>mjethanandani@gmail.com</div><div><br></div></div><=
br class=3D"Apple-interchange-newline"></div><br =
class=3D"Apple-interchange-newline"></div><br =
class=3D"Apple-interchange-newline" style=3D"caret-color: rgb(0, 0, 0); =
color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant-caps: normal; font-weight: normal; =
letter-spacing: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; =
word-spacing: 0px; -webkit-text-size-adjust: auto; =
-webkit-text-stroke-width: 0px; text-decoration: none;"><br =
class=3D"Apple-interchange-newline">
</div>
<br></div></div></body></html>=

--Apple-Mail=_727B7837-4339-4CDD-91B7-6F55F5DC6041--