[Cats] Re: Update version of CMAS

[Adrian Farrel <[e-mail]>]

Hi,

 

I think this is a good question and worth looking into in the context of the DAWN effort (https://datatracker.ietf.org/doc/dawn, https://datatracker.ietf.org/doc/bofreq-farrel-discovery-of-agents-workloads-and-named-entities/ and https://mailman3.ietf.org/mailman3/lists/dawn.ietf.org/) 

 

You’ll note that section 6.2 of https://datatracker.ietf.org/doc/draft-kay-dawn-use-cases/ mentions “compute resources” while section 7.3 is a place-holder for more discussion of this specific use case.

 

Cheers,

Adrian

 

From: [e-mail] <[e-mail]> 
Sent: 11 June 2026 10:34
To: [e-mail]
Cc: [e-mail]
Subject: [Cats] Re: Update version of CMAS

 

Hi, Bin

Thank you for the clarification. I have a follow-up question:

Could DNS serve as an alternative to the public service platform and achieve the same objectives? Given that DNS is already a widely deployed, distributed infrastructure for service naming and discovery, would it be more appropriate to leverage existing DNS mechanisms—potentially with new record types to carry service descriptions, deployment requirements, and CS-ID mappings—rather than introducing a separate platform component?

 

Best Regards!

Chuanyang

 

 

Original

From: 张宾 <[e-mail] <mailto:[e-mail]> >

To: 缪川扬10075421;

Cc: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >;

Date: 2026年06月09日 10:33

Subject: [Cats] Re: Update version of CMAS

-- 
Cats mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 

Hi Chuanyang,

 

 

Thank you for your careful review and constructive comments.

 

 

Regarding the first comment, our intention is that the public service platform serves as a supporting component for the CATS architecture rather than being limited to service-oriented metric definitions. The primary purpose of the platform is to provide a common reference for CS-ID interpretation, service descriptions, deployment requirements, and service context information. This allows clients, service sites, and network elements to have a consistent understanding of what a service identifier represents, especially in heterogeneous computing environments.

 

For example, if a client want to ask for a service, how he can find the proper CS-ID that fits for his service requirment if without the service platform?

 

At present, the information model focuses on service descriptions and deployment-related attributes because these are the most immediate requirements for practical CATS deployments. However, the design is intentionally extensible and can accommodate additional service-related information in the future if required by evolving CATS use cases. We agree that clarifying the intended scope and architectural role of the platform would improve readability, and we will consider adding explanatory text in the next revision.

 

 

Regarding the second comment, the draft intentionally avoids defining a mandatory onboarding or publication procedure. Different deployment environments may have different operational policies, trust models, and administrative requirements. Therefore, the draft focuses on the information structure of a service entry rather than prescribing how entries are created, validated, or maintained.

 

 

A service entry is expected to contain information such as service identifiers, service descriptions, deployment requirements, service sites, and service context. The actual publication and maintenance process is left to local implementation and operational policy. This flexibility is one of the key advantages of the proposed approach, as it allows service information to be published by service sites, platform operators, third parties, or clients without introducing additional protocol constraints. We agree that a brief explanation of this design choice would help readers better understand the operational model, and we will consider adding such text in a future revision.

 

 

Thank you again for your valuable feedback.

 

 

Best regards,

Bin

 

 

 

-----原始邮件-----
发件人: [e-mail] <mailto:[e-mail]> 
发送时间: 2026-06-08 22:31:46 (星期一)

收件人: [e-mail] <mailto:[e-mail]> 
抄送: [e-mail] <mailto:[e-mail]> 
主题: [Cats] Re: Update version of CMAS

 

Hi Authors,

Thank you for the work on this draft.

I read the document and think it is a useful contribution to the CATS WG. I have two comments for your consideration.

First, I am wondering whether the scope of the public service platform is intended to support the entire CATS architecture or primarily the service-oriented metrics definition. The current design appears closely aligned with service descriptions and deployment-related information. It may be helpful for the document to clarify whether the platform is envisioned as a general CATS component that could support other CATS functions in the future. A short discussion of the design scope boundaries could help readers better understand the intended role of the platform.

Second, it may be helpful to add a short description of the service onboarding or publication process. The draft mentions that a service entry may be published by a service site, platform operator, third party, or client. It may help readers if the document briefly describes what information is expected when a new service is published, and how the platform accepts or maintains such an entry according to local policy.

 

Best regards,

Chuanyang

 

 

 

 

 

From: 张宾 <[e-mail] <mailto:[e-mail]> >

To: [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >;

Date: 2026年05月29日 17:53

Subject: [Cats] Update version of CMAS

-- 
Cats mailing list -- [e-mail] <mailto:[e-mail]> 
To unsubscribe send an email to [e-mail] <mailto:[e-mail]> 

Hi all, 

 

  We have updated draft-zhangb-cats-cmas to make it better aligned with and supportive of the service-metrics-op draft.  

This version describes a  public service platform for CATS.  The platform maintains a common  service catalogue, associates public service identifiers with service descriptions and deployment requirements, and provides the service  context used by service-oriented metric mechanisms.

 

Link  draft-zhangb-cats-cmas-04 - Public Service Platform for Computing-Aware Traffic Steering (CATS) <https://datatracker.ietf.org/doc/draft-zhangb-cats-cmas/04/> 

 

We welcome any feedback on the mailing list.

 

Best regards,

Bin Zhang