Hi, Jason,
Thanks a lot for the review, much appreciated, please find some response below
inline...
From: Jason Sterne (Nokia) [mailto:[email protected]]
Sent: Wednesday, April 23, 2025 5:21 AM
To: Kent Watsen <[email protected]>; [email protected]
Subject: [netmod] Re: 2nd WGLC on immutable-flag
Hi all,
A few comments.
(A)
Section 5.1 says the following:
When a leaf node instance is immutable, it cannot change.
I was confused at first wondering why we didn't mention 'or be deleted'. Then I
got down to section 7 which clarified it. Maybe that's good enough but we could
also consider changing 5.1 to something like the following?
When a leaf node instance is immutable, it cannot be configured with a
different value in read-write configuration datastores (e.g. <candidate>,
<running>). It can be deleted in read-write configuration datastores (see
section 7).
(and then similar change of wording for other types of nodes)
[Qiufang] I think you might miss some text in sec.5:
"Throughout this section, the word "change" refers to creating, or deleting a
node, along with, where applicable, changing its value."
The life-cycle of immutable nodes are controlled by the server, thus it cannot
be created, updated, and deleted by the client.
It is different between deleting a node from <running> and from the operational
state. Sec.7 is clear that a client can create/delete immutable nodes in
<running>, which merely making the nodes visible/invisible in <running>.
I actually don't feel the need to state in sec.5 immutable node can be deleted
in read-write configuration datastore, because immutable configuration is not
present in <running> by default, only after a client copies the immutable
configuration into it, can it be deleted then, and sec.7 clarifies that in
detail.
Is this clear?
(B)
The details for leaf-list may be slightly unclear:
5.2. The "leaf-list" Statement
When a leaf-list node instance is immutable, it cannot change.
The immutable annotation attached to the individual leaf-list
instance provides immutability with respect to the instance itself.
A leaf-list as a whole can only inherit immutability from a parent
node (e.g., container), 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.
It may not be 100% clear what "leaf-list node instance" or "individual
leaf-list instance" is intended to mean. I believe it means each entry or value
of a leaf-list right?
[Qiufang] Yes.
How about something more like this?
5.2. The "leaf-list" Statement
The immutable property applies individually to each entry (each value) in a
leaf-list. In a single leaf-list, it is possible for some entries to be
immutable="true" and some entries to be immutable="false".
When an entry (value) in a leaf-list is immutable, it means that entry (value)
can't be deleted from the leaf-list in read-write configuration datastores. But
the immutable property has no bearing on whether the entry can be re-ordered
within the leaf-list.
[Qiufang] I guess I don't understand why an immutable entry cannot be deleted
from the read-write configuration datastores? This goes against with sec.7.
The individual entries (values) in a leaf-list inherit the immutability
property from a parent node (e.g. container) if they don't have their own
immutability specified.
The immutability of the leaf-list as a whole is not defined in this
specification. Immutability of the individual entries (values) has no bearing
on re-ordering within the leaf-list or adding/deleting other entries in the
leaf-list. Mechanisms for declaring the immutability of leaf-list entry
ordering and addition/deletion of leaf-list entries may be defined in future
documents
[Qiufang] There is some ongoing discussion with Kent about this point, feel
free to participate.
I agree not to add bearing on ordering and entry-addition/deletion of
leaf-list/list entries. You proposed "the immutability of the leaf-list as a
whole is not defined in this specification", but I think we should still
specify what if the leaf-list inherits immutability from a parent container,
and the current document states "this is identical to each individual leaf-list
entry being annotated...", is this needed?
And then perhaps show some examples, maybe like this:
In the my-leaf-list1 leaf-list (ordered-by user), the entry 'pear' is immutable
and can't be removed. The entries 'apple' and 'banana' can be removed. Any of
the entries, including 'pear', can be re-ordered.
In the my-leaf-list2 leaf-list (ordered-by user), the entries 'red' and
'yellow' are immutable and can't be removed. The entry 'blue' can be removed.
Any of the entries can be re-ordered.
<my-container1>
<my-leaf-list1 imma:immutable="false">apple</my-leaf-list1>
<my-leaf-list1 imma:immutable="true">pear</my-leaf-list1>
<my-leaf-list1 imma:immutable="false">banana</my-leaf-list1>
<my-container1>
<my-container2 imma:immutable="true">
<my-leaf-list2>red</my-leaf-list2>
<my-leaf-list2>yellow</my-leaf-list2>
<my-leaf-list2 imma:immutable="false">blue</my-leaf-list2>
<my-container2>
[Qiufang]Adding examples seems a good idea to me. When you say cannot be
removed, I think you are referring to being removed from <running>? But why? I
think if a client is able to create some configuration in <running>, it's
awkward if the client cannot delete it from <running> then.
I would assume in this example, all leaf-list entries can be removed, but the
entry with immutable=true would always be in use on the device if applied.
I think similar rewording might be better for lists as well (i.e. use "list
entry" terminology instead of "list instance").
(C)
The immutable annotation is only visible in read-only datastores. But might it
be useful to actually allow it to be returned in the <running> and <candidate>
in cases where a user has explicitly configured some things from the <system>
DS in their <running>? Maybe that has already been discussed?
[Qiufang]Yes, Rob had some comments regarding this, and he feels that it is
sufficient to only be visible in read-only datastores, and a client should have
the control over <running>. In some cases, configuring a different value for
immutable node won't cause an error, but just make the configuration not
applied.
Since immutable configuration is system-defined, a client can always fetch
<system> and understand which nodes are immutable. Make sense?
(D)
In the YANG model itself, the description of the annotation "immutable" doesn't
actually say what it does. Should we add something like this to the description?
Immutable nodes can be deleted from read-write datastores (e.g.
candidate and running), but can't be configured with a different value.
[Qiufang] Sure. But the proposed sentence feels kind of specific, e.g.,
configuring with a different value is only applicable to leaf statement. How
about the following being added to the description:
An immutable node cannot be created, deleted, or have its value changed on a
device, though a client may make it visible/invisible in read-write
configuration datastores.
Jason
Best Regards,
Qiufang
From: Kent Watsen <[email protected]<mailto:[email protected]>>
Sent: Wednesday, April 16, 2025 10:10 AM
To: [email protected]<mailto:[email protected]>
Subject: [netmod] 2nd WGLC on immutable-flag
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See the URL nok.it/ext for additional information.
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 -- [email protected]
To unsubscribe send an email to [email protected]
