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)
(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?
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.
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
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>
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?
(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.
Jason
From: Kent Watsen <kent+i...@watsen.net>
Sent: Wednesday, April 16, 2025 10:10 AM
To: netmod@ietf.org
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 -- netmod@ietf.org
To unsubscribe send an email to netmod-le...@ietf.org
