Hi, Jason, From: Jason Sterne (Nokia) [mailto:[email protected]] Sent: Tuesday, April 29, 2025 11:00 PM To: maqiufang (A) <[email protected]>; Kent Watsen <[email protected]>; [email protected] Subject: RE: [netmod] Re: 2nd WGLC on immutable-flag
Hello Qiufang, I'm a bit confused about this part: In some cases, configuring a different value for immutable node won't cause an error, but just make the configuration not applied Are we really going to allow a user to configure a different value for an immutable leaf in <running> than the value that is present in <system>? I know there might be some implementations that follow this way, but I don't want to advocate this behavior in the draft, since it is agreed what is in <running> always takes precedence over <system>. The drafts also states that " Clients may use "immutable" annotations provided by the server, to know beforehand why certain otherwise valid configuration requests will cause the server to return an error." Best Regards, Qiufang Jason From: maqiufang (A) <[email protected]<mailto:[email protected]>> Sent: Friday, April 25, 2025 4:35 AM To: Jason Sterne (Nokia) <[email protected]<mailto:[email protected]>>; Kent Watsen <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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:[email protected]] Sent: Wednesday, April 23, 2025 5:21 AM To: Kent Watsen <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[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]
