deleting a specific leaf-list

[kyoungyun]

Hi. From what I read in RFC 6020 (YANG), RFC 8040 (RESTCONF), and Andy Bierman's comment on https://mailarchive.ietf.org/arch/msg/netconf/QXJ-ind78nB3Qu2DIwngC_B7ZNM/, path to leaf-list can represent a single instance of leaf-list and deleting a specific leaf-list is allowed. Particularly, #66 seems to contradict what RFC 8040 says about deleting leaf-list.

This is what is said in #66 :

A leaf-list is an opaque value with regard to the path. There is no way to delete an individual element and a delete or addition to the list would be achieved by replacing the value of the leaf-list with a new leaf-list. The whole list can be removed by deleting the path to the list.

But this is what is said in RFC 8040:

If the target resource represents a configuration leaf-list or list data node, then it MUST represent a single YANG leaf-list or list instance. The server MUST NOT use the DELETE method to delete more than one such instance. (sec. 4.7)

I understand gNMI is gNMI and RESTCONF is RESTCONF, but at least for the way YANG is interpreted and handled, shouldn't there be some degree of consistency?

Also, there are valid situations where user wants to delete certain individual leaf-list instances without having to go through deleting all leaf-list instances and adding back the ones to be kept. Moreover, deleting all leaf-list instances and then adding back may cause unintended side-effects of toggling.

In RFC 8040 sec. 3.5.3:

The path segment is constructed by having the leaf-list name, followed by an "=" character, followed by the leaf-list value (e.g., /restconf/data/top-leaflist=fred).

This means that a specific leaf-list instance can be selected with leaf-list value (whereas a specific "list" instance can be selected with key name and key value). Along similar lines, would it be possible for gNMI Set to point to a specific instance of leaf-list with value? For example, a delete path for single leaf-list instance /foo/bar-leaf-list[somevalue] could be like:

path: { elem: { name: "foo" }, elem: { name: "bar-leaf-list", key: { key: "", value: "somevalue" } } }

I think this will improve usability with respect to leaf-list.

Thank you.

[robshakir]

Today, gNMI does not support this. There is no means to address a subelement of a leaf-list within the gNMI paths.

I, personally, don't find this a compelling use case to try and address w.r.t the complexity that it introduces into the path specification. There are two considerations that you raise:

• Applying the same configuration to a device may result in toggling of the features.
  • This behaviour is harmful, in general, and we should not encourage it in implementations AFAICS. Operationally, there are no cases that I can see whereby this implicit toggling is useful. If a user wants to toggle something they can always achieve it by removing it and reapplying the value explicitly. An implementation that can't reapply the same configuration without impacting the running state is really not able to operate declaratively, which is a significant part of the aim of having an interface like gNMI.
  • For this reason, I'd be against adding complexity to gNMI which is implemented across platforms that can do this to address what is essentially a defect of these systems IMHO,
• A user may want to not specify all values of a leaf-list.
  • The only use case that I can see for this is blindly deleting something from a list without knowing its contents. This seems strange -- how would one know that one wants to delete this value if one doesn't know what the current running values are? In almost all cases we know the values that should be running externally (e.g., from some declarative intent system), or by observation of the current running state. Given this is the case, it seems trivial to declaratively specify all values in the leaf-list rather than allow addressing of subelements.

I think there will always be differences between interfaces that allow a user to interact with a YANG-modelled datatree. Whether that be because they allow new behaviour (e.g., gNMI's Subscribe RPC is something that other implementations had not previously supported), or they provide a different operational model. The choice was explicitly made in the IETF to separate YANG semantics from the NETCONF semantics - I think this is the right division of functionality. A user should choose their interfaces based on their requirements.

Cheers, r.

[kyoungyun]

Today, gNMI does not support this. There is no means to address a subelement of a leaf-list within the gNMI paths.

I, personally, don't find this a compelling use case to try and address w.r.t the complexity that it introduces into the path specification. There are two considerations that you raise:

• Applying the same configuration to a device may result in toggling of the features.

  • This behaviour is harmful, in general, and we should not encourage it in implementations AFAICS. Operationally, there are no cases that I can see whereby this implicit toggling is useful. If a user wants to toggle something they can always achieve it by removing it and reapplying the value explicitly. An implementation that can't reapply the same configuration without impacting the running state is really not able to operate declaratively, which is a significant part of the aim of having an interface like gNMI.
  • For this reason, I'd be against adding complexity to gNMI which is implemented across platforms that can do this to address what is essentially a defect of these systems IMHO,

I think this is not precisely the same as my comment. My concern is not about applying the same configuration to a device but having to "delete" all leaf-list instances before applying new subset of the instances in order to emulate the delete of some instances, since gNMI does not support deleting individual leaf-list instance. So the concern I'm raising is not the same as, say, re-applying config leaf-lists A, B, C, and D to a device which already has A, B, C, and D BUT RATHER having to delete all leaf-lists (resulting in A, B, C, and D being "explicitly" toggled off) and then applying A and C because B and D cannot be deleted individually with gNMI.

• A user may want to not specify all values of a leaf-list.

• The only use case that I can see for this is blindly deleting something from a list without knowing its contents. This seems strange -- how would one know that one wants to delete this value if one doesn't know what the current running values are? In almost all cases we know the values that should be running externally (e.g., from some declarative intent system), or by observation of the current running state. Given this is the case, it seems trivial to declaratively specify all values in the leaf-list rather than allow addressing of subelements.

I didn't mention this as my concern. Not sure where this came from, but my concern is the opposite. User may WANT to specify specific value of a leaf-list to be deleted. gNMI currently doesn't let user specify specific value of a leaf-list to be deleted. gNMI only allowing deleting all leaf-lists makes user more prone to delete without knowing what the leaf-list values are. User is able to query all leaf-lists, and user should be able to choose which one of them to delete, not blindly delete all leaf-lists.

Also, I didn't think it would be too complex to reuse what's already defined for key name-value pair in PathElem. For referencing a list, name and value are filled in because list has named key. My suggestion is that gNMI could consider leaf-list as having unnamed key, so I thought using only value field could represent a single leaf-list instance.

I think there will always be differences between interfaces that allow a user to interact with a YANG-modelled datatree. Whether that be because they allow new behaviour (e.g., gNMI's Subscribe RPC is something that other implementations had not previously supported), or they provide a different operational model. The choice was explicitly made in the IETF to separate YANG semantics from the NETCONF semantics - I think this is the right division of functionality. A user should choose their interfaces based on their requirements.

Cheers, r.

[robshakir]

If we have /foo/bar which is a leaf-list which contains ["A", "B", "C", "D"], and you wish to remove B and C, then this can be done with gNMI. A Set operation that replaces /foo/bar with ["A", "D"] will do this without needing to address individual elements at all.

The concern that I raised about why this would need to be done is taking a step back about how the management system that interacts with the gNMI target is likely to operate. Understanding this operational model is really important for us to understand why the behaviour that you're suggesting might be needed.

[mahen-g]

Hi,

How about the below scenario ? The below is a leaf-list in Openconfig Model, which stores multiple values. By default, the target platform might not suppress anything to start with. Now the user goes ahead and suppresses the supported TLV's , but after a while wants to go back to the default behaviour of not suppressing anything. In this particular, the intent would be to delete the entire leaf-list.

/lldp/config/suppress-tlv-advertisement

Thanks,

[robshakir]

In that case, we have a delete in the proto - so you can specify the /lldp/config/suppress-tlv-advertisement leaf in that field and it'll be entirely removed.

[kyoungyun]

Just FYI, if you want to consider supporting what XPATH and YANG supports, here's an excerpt from RFC 6020 sec. 9.13.5 related to the "context node":

 /* instance-identifier for a leaf-list entry */
 /ex:system/ex:services/ex:ssh/ex:cipher[.='blowfish-cbc']

The XPATH spec. mentions the single dot (.) is used for context node. Not sure why it's difficult for gNMI to support though.

[robshakir]

We specifically don't try and replicate the XPATH functionality in gNMI, and rather focus on covering operators' use-cases rather than all possible features being covered. The more complex we make this specification, the more chance for divergence in implementations and lack of interoperability we have. NETCONF has shown the risk of this. At this point, I don't see strong demand for this feature -- such that it's not clear to me that the complexity that we would need to take on in the path format here is worth the benefits described above.