Hi Qiufang, Thank you for your response. Please find comments below.
I removed items that you noted as already fixed. Kent // contributor > On Apr 24, 2025, at 11:39 PM, maqiufang (A) <maqiufa...@huawei.com> wrote: > > Hi, Kent, > > Thanks for the good comments, please see my reply below inline. > > From: Kent Watsen [mailto:kent+i...@watsen.net] > Sent: Wednesday, April 16, 2025 11:20 PM > To: netmod@ietf.org <mailto:netmod@ietf.org> > Subject: [netmod] Re: 2nd WGLC on immutable-flag > > > Hi Authors, > > Reading the -03 diffs, some things caught my attention: > > 1) Section 4.2.2 contains the sentence: > "To enable a RESTCONF client to discover if the "with-immutability" query > parameter is supported by the server, the following capability URI is > defined: urn:ietf:params:restconf:capability:with-immutability:1.0". > · Is this capability RESTCONF specific? > [Qiufang] Yes, this capability is RESTCONF specific. Note there is a > “restconf” in the middle of the URI, and this aligns with the other > capability URIs defined in 8040 and 8527. Okay, I see that it aligns with the "with-defaults" and "with-origin" capabilities. > · Should this sentence be moved to the common-with-NETCONF Section > 4.2? > [Qiufang] Since this is intended to be RESTCONF specific, I don’t feel it > should be moved to sec.4.2. A side comment is that I never find any existing > capability URIs that works for both NC and RC, it seems that the consistent > style is to have the protocol name in the middle of the URI for specific > protocol. Good observation. My takeaway is that the capabilities are protocol-specific because they regard the function of the protocol itself. We really should rename it to "protocol capabilities" to avoid confusion. Side comment: features are always YANG-module specific. There can be some overlap if one puts an "if-feature" on an "rpc", "action", or "notification" statement. > · Isn't searching YANG Library an equally valid way to discover if > the server supports the flag? > [Qiufang] Yes for the NETCONF protocol. But for RESTCONF, it might be good > to be consistent with the definition of “with-defaults” and “with-origin” > query parameter. Agreed. > 3) Sections 5.2 (leaf-list) and Section 5.4 (list) contain the text > · "... as a whole can only inherit immutability from a parent node > (e.g., container). > · It might be helpful to state that this limitation is from RFC 7952. > [Qiufang] Take sec.5.2 leaf-list for example, would the following update work? > OLD: A leaf-list as a whole can only inherit immutability from a parent node > (e.g., container)… > NEW: As per the restrictions in RFC 7952, annotations cannot be attached to > an entire leaf-list instance and only > to individual leaf-list entries, which implies a leaf-list as a > whole can only inherit immutability from a parent node (e.g., container)… Yes. Thank you. > 4) Sections 5.2 (leaf-list) and Section 5.4 (list) contain the text: > · "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." > · Some of this text is from before, but some is new. After reviewing > the conversation for Rob's review, I'm unsure what prompted the new text. > · For lists, I don't agree with the immutability of a list is the > same as each entry being immutable. Of course, each list-entry may also be > immutable, but these are distinct things. IMO, an immutable list is one that > cannot have entries added, removed, or reordered (for "ordered-by user" > lists), where each "entry" is solely defined by its keys. This implies that > the list entry's keys are immutable (toggling to mutable has no affect) but > also that non-key parts of the list-entry may be *changed*, assuming the > list-entry is toggled to be immutable. > · For leaf-lists, since the entries are scalar, I agree that an > immutable leaf-list implies that the leaf-list entries are also immutable > (toggling to mutable has no affect). Again, for "ordered-by user" > leaf-lists, immutability should mean that the order cannot change either. > [Qiufang] Maybe this needs more discussion, but I recall at the interim we > had before when discussing this work, we kind of agree that we don’t want the > immutable flag to have bearing on the ordering/entries-adding/deleting. A > case that was similar to our previous discussion is, suppose there is an > immutable container with a couple of list entries inside it, so the list as a > whole is immutable as well, but there might be some other list entries that > were actually immutable=”false” and just deleted thus not appearing, the > clients should be able to add them back to the list. Yes, I think that we should discuss this more. For me, it is clear that an immutable list is one that cannot have items added, removed, or reordered. Of course, the list items can be changed (sans their "key" nodes), if they are toggled to be immutalbe=false. Think about a firewall's ACLs, the order matters! If the <system> datastore defines an "immutable=true" ACL, how can it be okay for <running> to reorder its ACL rules? > Maybe a better way to specify the immutability of leaf-list/list is to define > an YANG extension for this, but currently we leave this out of scope in the > draft. Do you mean to define immutability on the list as a whole? That is, to update RFC 7952? I'm okay with that being left out for now. > Also see some minutes from > https://datatracker.ietf.org/doc/minutes-interim-2024-netmod-02-202402061400/: > Annotation for a list or leaf-list overall: > not possible in XML encoding, so perhaps we should avoid it for all > encodings > annotation for individual list entries or leaf-list entries is fine > a parent container of the list may have the annotation, but that > should mean the same thing as each individual list entry being > annotated > in theory it could be done at the schema level with an extension Yes, I guess you meant "a a whole". FWIW, per my earlier comment, I disagree with the third point. Also from the Minutes: Does an immutable true tag on a user-ordered leaf-list entry prevent reordering of that entry (or other entries)? No. This immutable tag should have no bearing on order (allowing or preventing reordering). Perhaps another flag or extension could be used (as part of other future drafts) Gets complicated, especially with a mix of mutable and immutable entries in a list Would it just be the immutable entries that can't be reordered, and just with respect to each other? I think it was missed that, if a list is immutable, then no new entries can be added to it, so there is no worry about how/where the new entries may be ordered. Also, above, where it says "user-ordered" (i.e., ordered-by user), we really mean "system", since immutable lists are only be defined in the <system> datastore. I just want to clarify that "user" here doesn't mean the same thing as a "client". > 6) Section 9 (YANG Module) contains new "description" text: > > The 'with-immutability' parameter is only valid for a > system, intended, or operational datastore. If > 'with-immutability' is used with an invalid datastore, > then the server MUST return an <rpc-error> element > with an <error-tag> value of 'invalid-value'."; > > Is this text needed, given the "when" statement would cause a protocol > error otherwise? > [Qiufang] But there is no harm here, right? I think there might be some merit > for the second sentence to be kept, which gives the error-tag information and > aligns with the “with-origin” and “with-defaults” definition in 8526. Perhaps > remove this paragraph in YANG module and move the second sentence into the > normative section? Okay. I agree that "invalid-value" is correct. As for where to put the text, it might be helpful to look at how RFC 8040 does it in Section 4.8.9: Since the server does not report the "also-supported" parameter as described in Section 4.3 of [RFC6243], it is possible that some values for the "with-defaults" parameter will not be supported. If the server does not support the requested value of the "with-defaults" parameter, the server MUST return a response with a "400 Bad Request" status-line. The error-tag value "invalid-value" is used in this case. Kent // contributor
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
