[Cats] Re: Comments on draft-ietf-cats-metric-definition: in-band signalling of the normalization profile, and metric collection time

["Dikshit, Saumya" <[e-mail]>]

Hello Kehan,

  PR raised: https://github.com/saumzy-bot/draft-ietf-cats-metric-definition/blob/main/draft-ietf-cats-metric-definition.md

  It is narrower than what I described on the list. Section 7 already carries the
  RFC 8911-shaped registry entries, so the PR does not touch them. What it adds is the
  per-instance half: which function produced a value, when it was observed, and how long
  it stays valid, plus a small registry so the first of those has something stable to
  point at.

  The Section 4.2.2 change is the one worth the WG's attention. It is written so that
  registering a function fixes its identity without constraining which function an
  operator applies, which lets this document and Section 5.4 of the framework both stand
  as written now that framework-24 has entered the RFC Editor queue.

  On the open question from my last mail - whether the registry belongs here or in a
  short separate document - the PR assumes here. I will move it otherwise.

 I have mentioned above details in my previous email as well with few nits and an update.

  Thanks,
  Saumya

From: Dikshit, Saumya <[e-mail]>
Date: Tuesday, 4 August 2026 at 6:15 PM
To: Kehan Yao <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Cats] Comments on draft-ietf-cats-metric-definition: in-band signalling of the normalization profile, and metric collection time

Hi Kehan,

I will  surely open the PR.  I want to make couple points and please do let me know your opinion.

Suggested contents of PR :
-------------------------------

  -  A registry entry structure for CATS metrics along the lines RFC 8911 sets out for. performance metrics:

  *
     metric name, definition reference, the fixed input parameters,
  *
 the units, the measurement or estimation method, and the output type.


     RFC 8912 is the worked example of what a populated set looks like, and it is worth following closely enough that a CATS registry does not need its own conventions.

  -  A small set of fields carried with a metric instance rather than with its definition:

  *
the identity of the normalization function applied,
  *
the instant of observation, and
  *
the interval for which the value is considered valid.

The second set is the part that matters operationally, and it is what the freshness question raised on 28 July is really asking for.
 A consumer that receives two values cannot currently tell:

  *
whether they disagree,
  *
or whether they were normalized differently,
  *
or whether one of them has simply expired.

Those are three different situations and only the first is a fault.

What has changed - Section 5.4 alignment can no longer be done in the framework :
--------------------------------------------------------------------------------------------------------

the Section 5.4 alignment to the framework editor for draft-ietf-cats-framework-24
is now in the RFC Editor queue, so that text is settled.

That leaves the reconciliation to be made from this document's side, which I think is workable and possibly better.

  *
Section 5.4 of the framework requires that a set of normalization and aggregation functions be standardized.
  *
Section 4.2.2 here states that they are implementation-specific and operator-controlled.

A registry satisfies both readings rather than choosing between them:

  *
 the functions that are registered are the standardised set, an operator remains free to apply others,
  *
and the identity field says which was used. .

I suggest lets write it that way than have the two documents read as contradicting each other once the framework is published. Your thoughts?

One Clarification needed:
--------------------------------

Does the WG want the registry defined in this document, or in a short separate one?


  *
 In-document keeps it together and needs no new draft, but it adds IANA considerations to a document whose IESG submission milestone has already passed.

  *
  A separate document leaves this one free to complete, and lets the registry take the IANA review time it needs without holding the metric definitions behind it.

If it helps, I can put the structure up as a PR against this document first so there is something concrete to look at, and moving it later will have a reference

I made a related comment on draft-ietf-cats-oam-fw on 3 August:

  *
 Section 5.2.1: requires detecting inconsistency between values obtained by push and by pull,
  *
which is the same dependency seen from the OAM side.

In summary, the three points are one position, not three.

Thanks,
Saumya Dikshit

From: Kehan Yao <[e-mail]>
Date: Tuesday, 4 August 2026 at 10:02 AM
To: Dikshit, Saumya <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Cats] Comments on draft-ietf-cats-metric-definition: in-band signalling of the normalization profile, and metric collection time

Hi Saumya,

I am more than happy to collab and write the text, that propose the registry entry structure along RFC 8911 lines,
and take the Section 5.4 alignment to the framework editors so the two land consistently.

Welcome PR here https://github.com/ietf-wg-cats/draft-ietf-cats-metric-definition

Best,
Kehan