[Cats] Re: Metric I-D [Was: What's next for CATS? Vienna and beyond]

[Jordi Ros Giralt <[e-mail]>]

Thanks Adrian, good feedback as usual.

Also as usual we just created a ticket so we can address your comments in the next draft updates: https://github.com/ietf-wg-cats/draft-ietf-cats-metric-definition/issues/37

Best,
Jordi
________________________________
From: Adrian Farrel <[e-mail]>
Sent: Friday, May 29, 2026 11:06
To: 'Kehan Yao' <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [Cats] Metric I-D [Was: What's next for CATS? Vienna and beyond]


WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

Hi Keahn.



Thanks for engaging with this.



> 1.      Have all outstanding issues been addressed? The authors should be
> able to answer this.

[KY] In the last two revisions, we have addressed the majority of the issues. There are still a few minor ones left, for example:

* Score direction – it is still opposite to the IGP metric usage; we need to discuss this further.



[AF] Yes, the WG needs to discuss this more.

In some ways, it is not very significant at all: just make it clear in the document.

I have a slight preference for “more expensive” being a higher number. That is partly to keep it consistent with the IGP metrics, and partly because it allows scope for continued increasing “expense”.

* Regarding metric encoding – we would like to compare using binary encoding or text encoding? Do you think we should add some discussion on this in the document?



[AF] I don’t believe this document needs to do that “beauty contest.”

It is important that you make an informed decision, and it may help to explain that decision on the list.

In the document, it is probably enough to capture this in just one or two sentences: “This document chooses to do x because of the following benefits. It would be possible to consider y, but that has the following drawbacks.”

* You commented on Section 6 before that you would like to see the description of where metric aggregation/normalization is placed should appear earlier and more centrally in the document.



[AF] Yeah. It’s not a big deal and shouldn’t need a lot of text. I just think that aggregation/normalization is fundamental to this work and we shouldn’t have to wait until Section 6 to find it.

It may be as simple as noting early in the document that this is a key part of the process and then supplying a forward pointer.



I am wondering whether the three points above could be combined into a new Operational Considerations section?



[AF] I definitely think that an operational Considerations section will add a lot to this document. But I am not sure that these three points are operational considerations so much as design choices.



Best,

Adrian