Based on this "top level comment", if I go back to my first comment (A) below:
(A) Section 5.1 says the following: When a leaf node instance is immutable, it cannot change. The immutable annotation is only provided when you query the <system>, <intended> and <operational>. *No* nodes in those datastores can change. They are all "immutable". That's why I proposed describing it more like this: 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). That describes the behavior of the leaf in the *running* which is what is actually relevant IMO. Jason From: Jason Sterne (Nokia) <jason.sterne=40nokia....@dmarc.ietf.org> Sent: Tuesday, April 29, 2025 11:07 AM To: maqiufang (A) <maqiufa...@huawei.com>; Kent Watsen <kent+i...@watsen.net>; netmod@ietf.org Subject: [netmod] Re: 2nd WGLC on immutable-flag I have a bit of a top level comment/discussion (based on some of the replies below). The <system> DS can't be modified by a client/user. A user/client can copy values from the <system> DS into the <running> DS. IMO the scope of the immutable flag is really only to describe limitations on those copied values in the <running>. *Nothing* can be deleted or changed (by a user/client) in the <system> DS. So there isn't really any need to describe what leafs can and can't be deleted in the <system> DS itself. So while the immutable annotation may be present in the <system> DS, it isn't actually describing any behavior of those nodes in the <system> DS. It is only describing how those nodes behave (for client writes) in the *<running>* DS. Unless I'm misunderstanding something basic here... Jason From: maqiufang (A) <maqiufa...@huawei.com<mailto:maqiufa...@huawei.com>> Sent: Friday, April 25, 2025 4:35 AM To: Jason Sterne (Nokia) <jason.ste...@nokia.com<mailto:jason.ste...@nokia.com>>; Kent Watsen <kent+i...@watsen.net<mailto:kent+i...@watsen.net>>; netmod@ietf.org<mailto:netmod@ietf.org> Subject: RE: [netmod] Re: 2nd WGLC on immutable-flag Hi, Jason, Thanks a lot for the review, much appreciated, please find some response below inline... From: Jason Sterne (Nokia) [mailto:jason.sterne=40nokia....@dmarc.ietf.org] Sent: Wednesday, April 23, 2025 5:21 AM To: Kent Watsen <kent+i...@watsen.net<mailto:kent+i...@watsen.net>>; netmod@ietf.org<mailto:netmod@ietf.org> 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 <kent+i...@watsen.net<mailto:kent+i...@watsen.net>> Sent: Wednesday, April 16, 2025 10:10 AM To: netmod@ietf.org<mailto: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
