Hi Jason, This sounds right to me.
Kent // contributor > On Apr 29, 2025, at 11:06 AM, Jason Sterne (Nokia) <[email protected]> > wrote: > > 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) <[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 <http://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]
