Return-Path: X-Original-To: cats@mail2.ietf.org Delivered-To: cats@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id D324BFF3FFE4 for ; Thu, 11 Jun 2026 02:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1781170915; bh=WlfLQ7nL8AvNzl5D4Mlu3GFOuOfd1v8NKafjzqcbV4Q=; h=Reply-To:From:To:Cc:References:In-Reply-To:Subject:Date; b=BoGDXng4EWoyF0oMn8K3NvFOeakZPn6ybBH8Uuw90iIb4I+fAb+dj1a0So+kiZ0E3 T6/LrQq6EVT2l1fGNmQndox0sBTY4kqfMldu1hQ8uv4kIMcHVpVmKbd5d3gFcQmakN OEcdp/ZCNB+X7G1Gil6XNI+cu72yDeE9ICsHkI08= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.795 X-Spam-Level: X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=olddog.co.uk Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwwkBIhMQ4fo for ; Thu, 11 Jun 2026 02:41:54 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 479ACFF3FF26 for ; Thu, 11 Jun 2026 02:40:57 -0700 (PDT) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta8.iomartmail.com (8.14.7/8.14.7) with ESMTP id 65B9eoF3000496; Thu, 11 Jun 2026 10:40:50 +0100 Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1BBE74604B; Thu, 11 Jun 2026 10:40:49 +0100 (BST) Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0EFCA4603D; Thu, 11 Jun 2026 10:40:49 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS; Thu, 11 Jun 2026 10:40:49 +0100 (BST) Received: from LAPTOPK7AS653V (82-69-109-75.dsl.in-addr.zen.co.uk [82.69.109.75]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.7/8.14.7) with ESMTP id 65B9emP3027506 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Jun 2026 10:40:48 +0100 From: "Adrian Farrel" To: , References: 27aaae0f.6b5c.19e73266560.Coremail.zhangb@pcl.ac.cn,20260608223146306PyMvdWH313rmmKc-73ePG@zte.com.cn,58cab8a9.7541.19eaa3a18c6.Coremail.zhangb@pcl.ac.cn <20260611173422013MPCiM2lgRLiEPSQSAWyVX@zte.com.cn> In-Reply-To: <20260611173422013MPCiM2lgRLiEPSQSAWyVX@zte.com.cn> Date: Thu, 11 Jun 2026 10:40:48 +0100 Organization: Old Dog Consulting Message-ID: <1c1e01dcf986$62a95270$27fbf750$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1C1F_01DCF98E.C46DBA70" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQHOTWEnf46ziyh7pGHJMTo7WFMjb7ZWcOiQ X-Originating-IP: 82.69.109.75 X-Thinkmail-Auth: adrian@olddog.co.uk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=olddog.co.uk; h=reply-to :from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type; s=20221128; bh=WlfLQ7nL8AvNzl5D4Mlu3 GFOuOfd1v8NKafjzqcbV4Q=; b=xZ9rAqFo/nPXG0aPKF8ZlYtD6sPeHBndG1jVK 2Z/pL1/cALKflMjWpOwO9BXTWziaO3PaPvXnb2sxCCt1eXZ9gajnBt2j6Yfjekst Ah9QfiHHkvSXsH1C78g6u2kYNOyR1SJw9volyc+T6xvdUv583CPNleKNtaG6pjiv mbsdTbdBqrSjBuzkHsCoW0WCL7xU8LWETGitDp4w8QES51N4hRXl+nu9eBwx3ZQP YRfFxg0topwZSQqJP94NXZvFkD3C3j/mdPo9DNgHLGng51zm85YE8mhstPIFS790 O5LpOfAT0D6zVMZoTNBXx+9BsceMjzD+nPE0Tkd2LWKsWD3aw== X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1006-29464.005 X-TM-AS-Result: No--33.259-10.0-31-10 X-imss-scan-details: No--33.259-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1006-29464.005 X-TMASE-Result: 10--33.258900-10.000000 X-TMASE-MatchedRID: RvgD6ijzkWnuYusHgJkgyhK8RjA2ODb7O0u5ECU9OSQ8muUcmU90rgPy qRKygzRKVassfZx9nB3CmFWKuIa6/OUtBPZr9kvNFInyGi5rPwIVdewhX2WAAZ/bL8lMFJRVKiV Y4AyDZ9w40wirq0mM9cQTSPZE5H8gARprIm1hk20bVzFi+tzvL+PsX9qV3arkc2uURv2pMpRl54 /GzuP0syEXkRzrpr4M2j+JKM2tKV0K3Ma88LL+bo0GmoK+JfmTBmndz/Xn9j1Ox35wf8X3qg/zh aXEgL8LEyl5m1YoJPQcKFYeDmCMal/ZJ0h1vLl1aXmdXF2Ym8e8MakitBkj0e/m0bmpDCNAh7w8 b9AwvtVbtzD5SJbjLh2mQZVcW1xaDz7vpfsrKwzlsyZ05iz8bxdHX2eZFfZfsFlRyVSK9Lw8AAj HVTD4+prebk37wacme3bcH73AUEjsu44QBj0GpJfau+Sc1iUTIJP1u7X3VNCyOf3T1hTX87suS/ c2FNRNfEf7Bse5VqwvsNfQP2YlFWgws6g0ewz2VRsRKWlbgW0cGs0SeF+d0xzi0sk/gjqXBpMjt ZwbqtdiOz1/Ja1KMBeAuxqienA92lEopZEM4IyNBk0ph2w4VeR/0uYWk1E1srg1EArQJcdbWiC/ 406EzEej3sxQoy96qI7FT/qLDchswYo64ufkVRsEUOLXxaXgylABiRBSWe0Ou5CaMi/bTidqNdJ tmywSoOhjArOhCHXdrEfmr4xA4B1kSRHxj+Z5SdIdCi8Ba4DVbZFdXapsKfk3psCmqv7TgMBtpm l0DCBJpV9rHFX3j7MwnTKgkbsOwbRQ2BpmlipKHhaQPPG6/o5hyiW8kJaQiJtHLSORchni8zVgX oAlttVnSDvjSUv5BLPx9cDMrKYiFsjht1RR48fzmkh/RCpbYxeu+Iqmk8ErN8z0HohG3jcB+yPH wBUaWWBpKYWJwLID/dHyT/Xh7Q== X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 Message-ID-Hash: TYOIKLC4OOF2KTOCHLBLMMP52G5MARD3 X-Message-ID-Hash: TYOIKLC4OOF2KTOCHLBLMMP52G5MARD3 X-MailFrom: adrian@olddog.co.uk X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: cats@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Reply-To: adrian@olddog.co.uk Subject: =?utf-8?q?=5BCats=5D_Re=3A_Update_version_of_CMAS?= List-Id: "Computing-Aware Traffic Steering (CATS)" Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multipart message in MIME format. ------=_NextPart_000_1C1F_01DCF98E.C46DBA70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, =20 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-worklo= ads-and-named-entities/ and = https://mailman3.ietf.org/mailman3/lists/dawn.ietf.org/)=20 =20 You=E2=80=99ll note that section 6.2 of = https://datatracker.ietf.org/doc/draft-kay-dawn-use-cases/ mentions = =E2=80=9Ccompute resources=E2=80=9D while section 7.3 is a place-holder = for more discussion of this specific use case. =20 Cheers, Adrian =20 From: miao.chuanyang@zte.com.cn =20 Sent: 11 June 2026 10:34 To: zhangb@pcl.ac.cn Cc: cats@ietf.org Subject: [Cats] Re: Update version of CMAS =20 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=E2=80=94potentially with new record types to carry service = descriptions, deployment requirements, and CS-ID mappings=E2=80=94rather = than introducing a separate platform component? =20 Best Regards! Chuanyang =20 =20 Original From: =E5=BC=A0=E5=AE=BE > To: =E7=BC=AA=E5=B7=9D=E6=89=AC10075421; Cc: cats@ietf.org >; Date: 2026=E5=B9=B406=E6=9C=8809=E6=97=A5 10:33 Subject: [Cats] Re: Update version of CMAS --=20 Cats mailing list -- cats@ietf.org =20 To unsubscribe send an email to cats-leave@ietf.org = =20 Hi Chuanyang, =20 =20 Thank you for your careful review and constructive comments. =20 =20 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. =20 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? =20 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. =20 =20 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. =20 =20 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. =20 =20 Thank you again for your valuable feedback. =20 =20 Best regards, Bin =20 =20 =20 -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: miao.chuanyang@zte.com.cn = =20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2026-06-08 22:31:46 = (=E6=98=9F=E6=9C=9F=E4=B8=80) =E6=94=B6=E4=BB=B6=E4=BA=BA: zhangb@pcl.ac.cn =20 =E6=8A=84=E9=80=81: cats@ietf.org =20 =E4=B8=BB=E9=A2=98: [Cats] Re: Update version of CMAS =20 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. =20 Best regards, Chuanyang =20 =20 =20 =20 =20 From: =E5=BC=A0=E5=AE=BE > To: cats@ietf.org >; Date: 2026=E5=B9=B405=E6=9C=8829=E6=97=A5 17:53 Subject: [Cats] Update version of CMAS --=20 Cats mailing list -- cats@ietf.org =20 To unsubscribe send an email to cats-leave@ietf.org = =20 Hi all,=20 =20 We have updated draft-zhangb-cats-cmas to make it better aligned with = and supportive of the service-metrics-op draft. =20 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. =20 Link draft-zhangb-cats-cmas-04 - Public Service Platform for = Computing-Aware Traffic Steering (CATS) = =20 =20 We welcome any feedback on the mailing list. =20 Best regards, Bin Zhang =20 =20 ------=_NextPart_000_1C1F_01DCF98E.C46DBA70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

I think this is a good question and worth looking into in = the context of the DAWN effort (https://datatracker.ietf.o= rg/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=E2=80=99ll note that section 6.2 of https= ://datatracker.ietf.org/doc/draft-kay-dawn-use-cases/ mentions = =E2=80=9Ccompute resources=E2=80=9D while section 7.3 is a place-holder = for more discussion of this specific use case.

 

Cheers,

Adrian

 

From:<= /b> = miao.chuanyang@zte.com.cn <miao.chuanyang@zte.com.cn> =
Sent: 11 June 2026 10:34
To: = zhangb@pcl.ac.cn
Cc: cats@ietf.org
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=E2=80=94potentially with new record types to carry = service descriptions, deployment requirements, and CS-ID = mappings=E2=80=94rather than introducing a separate platform = component?

 

Best = Regards!

Chuanyang

 

 

Original

From: =E5=BC=A0=E5=AE=BE <zhangb@pcl.ac.cn>

To: =E7=BC=AA=E5=B7=9D=E6=89=AC10075421;

Date: 2026=E5=B9=B406=E6=9C=8809=E6=97=A5 = 10:33

Subject: [Cats]= Re: Update version of = CMAS

-- 
Cats mailing list -- cats@ietf.org
To unsubscribe&nb= sp;send an email to cats-leave@ietf.org

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

 

 

 

-----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6-----
=E5=8F=91=E4=BB=B6=E4=BA=BA= : miao.chuanyang@zte.com.cn=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2026-06-08 22:31:46 (=E6=98=9F=E6=9C=9F=E4=B8=80)

=E6=94=B6=E4=BB=B6=E4=BA=BA: zhangb@pcl.ac.cn
<= span style=3D'font-size:10.5pt;font-family:"MS = Gothic"'>=E6=8A=84=E9=80=81: cats@ietf.org
=E4=B8=BB=E9=A2=98: [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: =E5=BC=A0=E5=AE=BE <zhangb@pcl.ac.cn>

Date: 2026=E5=B9=B405=E6=9C=8829=E6=97=A5 = 17:53

Subject: [Cats]= Update version of = CMAS

-- 
Cats mailing list -- cats@ietf.org
To unsubscribe&nb= sp;send an email to cats-leave@ietf.org

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=C2=A0 public service platform for =
CATS.=C2=A0 The platform maintains a common=C2=A0 service catalogue, =
associates public service identifiers with service descriptions and =
deployment requirements, and provides the service=C2=A0 context used by =
service-oriented metric mechanisms.

 

 

We welcome = any feedback on the mailing list.

 

Best = regards,

Bin = Zhang

 

=

 

------=_NextPart_000_1C1F_01DCF98E.C46DBA70--