Hi, Kent, Thanks for the good comments, please see my reply below inline.
From: Kent Watsen [mailto:[email protected]] Sent: Wednesday, April 16, 2025 11:20 PM To: [email protected] 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. · 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. · 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. A RESTCONF server implementing the yang module (searching YANG library) indicates that it supports the get-data RPC operation with the flag; while the flag defined as the query parameter is added to the GET method, so I don’t feel they are the same. Note 8527 does require the usage of the YANG library, but it also defines the query parameter and related capability URI for “with-defaults” and “with-origin” parameters. 2) s/creating, or deleting a node/creating or deleting a node/ (remove comma) [Qiufang] Fixed. 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)… 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. 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. 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 5) Section 5.3 (container) and 5.4 (list) contain the text: · "Descendant nodes of the container recursively inherit the immutability of the container, unless the immutability is overridden by an immutable="false" annotation on a descendant node." · This text regards toggling immutability one direction, though the statement is true for both directions. · I suggest this instead: o Descendant nodes of the container recursively inherit the immutability of the container, unless the immutability is overridden by an "immutable" annotation on a descendant node. [Qiufang] Sure, fixed. 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? 7) Section A.4 (LNE) · The reference to RFC 8530 seems out of place. Maybe this? o OLD: A logical network element (LNE) is an independently managed virtual network device made up of resources allocated to it from its host or parent network device [RFC8530]. o NEW: A logical network element (LNE), as described in [RFC8530], is an independently managed virtual network device made up of resources allocated to it from its host or parent network device. [Qiufang] Fixed. Thanks a lot. Kent // contributor Best Regards, Qiufang On Apr 16, 2025, at 10:09 AM, Kent Watsen <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
