Hi Authors,
Reading the -03 diffs, some things caught my attention:
1) Section 4.2.2 contains the sentence:
"To enable a RESTCONF client to discover if the "with-immutability" query
parameter is supported by the server, the following capability URI is defined:
urn:ietf:params:restconf:capability:with-immutability:1.0".
Is this capability RESTCONF specific?
Should this sentence be moved to the common-with-NETCONF Section 4.2?
Isn't searching YANG Library an equally valid way to discover if the server
supports the flag?
2) s/creating, or deleting a node/creating or deleting a node/ (remove comma)
3) Sections 5.2 (leaf-list) and Section 5.4 (list) contain the text
"... as a whole can only inherit immutability from a parent node (e.g.,
container).
It might be helpful to state that this limitation is from RFC 7952.
4) Sections 5.2 (leaf-list) and Section 5.4 (list) contain the text:
"but that is identical to each individual leaf-list entry being annotated and
has no bearing on the entry ordering and addition of new entries. Mechanisms
for declaring the immutability of leaf-list entry ordering and addition of new
leaf-list entries may be defined in future documents."
Some of this text is from before, but some is new. After reviewing the
conversation for Rob's review, I'm unsure what prompted the new text.
For lists, I don't agree with the immutability of a list is the same as each
entry being immutable. Of course, each list-entry may also be immutable, but
these are distinct things. IMO, an immutable list is one that cannot have
entries added, removed, or reordered (for "ordered-by user" lists), where each
"entry" is solely defined by its keys. This implies that the list entry's keys
are immutable (toggling to mutable has no affect) but also that non-key parts
of the list-entry may be *changed*, assuming the list-entry is toggled to be
immutable.
For leaf-lists, since the entries are scalar, I agree that an immutable
leaf-list implies that the leaf-list entries are also immutable (toggling to
mutable has no affect). Again, for "ordered-by user" leaf-lists, immutability
should mean that the order cannot change either.
5) Section 5.3 (container) and 5.4 (list) contain the text:
"Descendant nodes of the container recursively inherit the immutability of the
container, unless the immutability is overridden by an immutable="false"
annotation on a descendant node."
This text regards toggling immutability one direction, though the statement is
true for both directions.
I suggest this instead:
Descendant nodes of the container recursively inherit the immutability of the
container, unless the immutability is overridden by an "immutable" annotation
on a descendant node.
6) Section 9 (YANG Module) contains new "description" text:
The 'with-immutability' parameter is only valid for a
system, intended, or operational datastore. If
'with-immutability' is used with an invalid datastore,
then the server MUST return an <rpc-error> element
with an <error-tag> value of 'invalid-value'.";
Is this text needed, given the "when" statement would cause a protocol
error otherwise?
7) Section A.4 (LNE)
The reference to RFC 8530 seems out of place. Maybe this?
OLD: A logical network element (LNE) is an independently managed virtual
network device made up of resources allocated to it from its host or parent
network device [RFC8530].
NEW: A logical network element (LNE), as described in [RFC8530], is an
independently managed virtual network device made up of resources allocated to
it from its host or parent network device.
Kent // contributor
> On Apr 16, 2025, at 10:09 AM, Kent Watsen <kent+i...@watsen.net> wrote:
>
> This email begins a 2nd two-week WGLC on:
>
> YANG Metadata Annotation for Immutable Flag
> https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/03/
>
> The first WGLC didn't succeed due to insufficient responses. For those that
> responded before, there is no need to respond again. For others, please take
> time to review this draft and post comments by Apr 30. Both favorable
> comments and objections are welcomed.
>
>
> FWIW, all authors (there are no contributors) have responded to being unaware
> of any IPR that applies to this document:
>
>
> https://mailarchive.ietf.org/arch/msg/netmod/jh5JXtvraZozmZCEcQr1zL-Y0HQ/
>
>
> Kent (and Lou)
> _______________________________________________
> netmod mailing list -- netmod@ietf.org
> To unsubscribe send an email to netmod-le...@ietf.org
_______________________________________________
netmod mailing list -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
