Ordering of /qos/classifiers/classifier/terms/term

[pandurangan-arista]

Each term has a set of match conditions and an associated action and we could have multiple terms within a classifier. However it is not clear how to order the terms (in case the terms have overlapping match criteria, the order would determine the term and action that gets applied).

For example, in ACL model, we have this clearly defined using sequence-id, but the same isn't clear in case of /qos/classifiers/classifier/terms/term.

[dplore]

Thanks for identifying this issue. To get deterministic support of the current model we do need a sequence id. The next choice is how to model this.

1. Sequence-id be introduced as a new leaf and not part of the key, a non-breaking change.
2. Create a new list (such as ordered-terms/ordered-term) which is ordered and uses sequence-id as a key.
3. This could be introduced as a new leaf and made part of the list key, a major breaking change.
4. Changing the existing term/config/id to be a sequence in some way, also a major breaking change.

Option 1 and 2 are really the only options for operators who are using this tree now (Google is).

[ElodinLaarz]

Discussed in OC Operators Meeting Dec 2nd - Since there's some implementation / usage (despite being version 0), we would want to lean towards a non-breaking change (and promote the model version to v1).

Could be useful to discuss at the Community Meeting, as well, but creating a specific PR / aligning on a particular implementation could be beneficial ahead of time to guide the discussion.

[rgwilton]

@dplore Why not just order it by term/id, the list key. This is what we are doing when we are mapping this configuration. Perhaps marking this as ordered-by-user might be the right answer.

[ElodinLaarz]

Discussed in OC Operators Meeting March 3rd, 2026:

RE: Ordering by term/id -- since the leaf is a string, there's no reason that the ordering of the strings should give an expected ordering. Ordering by user seems reasonable, though this is also a breaking change, which we would want to avoid.

An alternate choice here is to not fix this particular issue and move to using the match action rules from #1417

We still suggest proposing a particular PR, if anyone has a particular expectation / use-case. Getting more vendor input would be useful here.

[dplore]

@pandurangan-arista any opinion on which way you want to go for a pull request?

My recommendation is to propose adding sequence-id as a new leaf and not part of the key, a non-breaking change.

[PranavAdityaCP]

Hello team , as per the discussions above , I have introduced sequence-id as a new leaf (non-key) in the paths

/qos/classifiers/classifier[name=*]/terms/term[id=*]/config/
/qos/classifiers/classifier[name=*]/terms/term[id=*]/status/

Please find the PR for the same : #1526

[pandurangan-arista]

@pandurangan-arista any opinion on which way you want to go for a pull request?

My recommendation is to propose adding sequence-id as a new leaf and not part of the key, a non-breaking change.

Thanks @PranavAdityaCP for the PR. @dplore We can go ahead with your recommendation