Re: [Dots] some nits and comments about draft-dots-signal-channel-23:

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Wed, 29 August 2018 07:41 UTC

Return-Path: <TirumaleswarReddy_Konda@mcafee.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9CD130E30; Wed, 29 Aug 2018 00:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDdc5YMgDj1P; Wed, 29 Aug 2018 00:41:47 -0700 (PDT)
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF4812008A; Wed, 29 Aug 2018 00:41:47 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1535528517; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-ms-exchange-senderadcheck:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-microsoft-antispam-message-info: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=n 9yn4ISVrqzXNonZKXBtQ9UnDZRXVNNUaV3AaEU4ko g=; b=bKwWz+5S1S0i3ZA0ITkf8MvIxnZeWhf43l1oDtpmxys/ QhGAtqc13hSQ67gHyTpozNfJd1redD6vTEAdOlQqBrEpQHxSlT 4CUt2lk3raJCRSywumhU6ODB17gaMewYi1OvjdwcGP0i9kuGmJ o4MO5T+vkaKXKAWCVEjKRiNEYNc=
Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 62bc_e720_07849d0a_7bde_4ccb_a877_be2725ad5554; Wed, 29 Aug 2018 02:41:56 -0500
Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 29 Aug 2018 01:41:39 -0600
Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 29 Aug 2018 01:41:38 -0600
Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 29 Aug 2018 01:41:38 -0600
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 29 Aug 2018 01:41:37 -0600
Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB0004.namprd16.prod.outlook.com (10.172.111.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1080.17; Wed, 29 Aug 2018 07:41:35 +0000
Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::70b9:d1c3:ceda:596]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::70b9:d1c3:ceda:596%4]) with mapi id 15.20.1080.015; Wed, 29 Aug 2018 07:41:35 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: "Xialiang (Frank, Network Integration Technology Research Dept)" <frank.xialiang@huawei.com>, "draft-ietf-dots-signal-channel.authors@ietf.org" <draft-ietf-dots-signal-channel.authors@ietf.org>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: some nits and comments about draft-dots-signal-channel-23:
Thread-Index: AdQ7fkPcZXaZ/b/SQr2JzmmZxhn5iAADTsyAALlvKeAACZzwUAAoKpjAAAfra5A=
Date: Wed, 29 Aug 2018 07:41:35 +0000
Message-ID: <BN6PR16MB1425362E99AE92CB4271B55FEA090@BN6PR16MB1425.namprd16.prod.outlook.com>
References: <C02846B1344F344EB4FAA6FA7AF481F12C851E42@dggemm511-mbs.china.huawei.com> <BN6PR16MB14254170346ECA688FB485D0EA350@BN6PR16MB1425.namprd16.prod.outlook.com> <C02846B1344F344EB4FAA6FA7AF481F12C855E79@dggemm511-mbx.china.huawei.com> <BN6PR16MB1425DDE9F8C3F75A8F798222EA0A0@BN6PR16MB1425.namprd16.prod.outlook.com> <C02846B1344F344EB4FAA6FA7AF481F12C8567D9@dggemm511-mbx.china.huawei.com>
In-Reply-To: <C02846B1344F344EB4FAA6FA7AF481F12C8567D9@dggemm511-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.0.500.52
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [103.245.47.20]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR16MB0004; 6:+cmJI5sZGa8IJSHtreEtx4KTPvDub0yOgfJ21mYvQ6QXj879eQ7axK+hP4kZAHgeW/LNyn60a9dmy2hmZn9orklthYTKOyy9+irnQCQD+mBFavo/3JSbPoLwrHJJwqNdJI5/hdyFjRvlvfdBTKdn4H/hga/j7Wc6BCL2PJbIXjpDqBZUBlxhhN2ekfe6oEBBoYmE28lTxxwrHC5kruR588cesqloCxv5kBbBJR/oEKIGPHl857mUpu9JiPx9AnIKYAFGEOIaLO1DlhtTbXhczggRaiA4tD30qv0eVQGoU3gq6L+MPdXg+RlqKKqf2YsV8R9mrvebI0MiMhUSgIzLgkZhbjNOjYXrr4Kz1W8Ar/gW/Avuu9KEU2vHDV9+fY82UOdDs/lwN6fmKXqtx1qCtKH2I0rtmLy6MBEUgFt1VrfxsuKW26637JIrqDsPN9ygww3ND1aMnEkuSbcG26VuTg==; 5:QpPWhudPPSi5a10bfDhchCKDncV4cQsQ8Sc2HZKctEOJ6hC0bS0bMM7XAceN6aGnWmfzINwCsoDO/kom5QNmxtn1Vpoc3Au25xz/uJgAkICldpMs51Gd+mrDaPMl6THDVf3c8lP1trU/qKERKorzRxEmMes2b4VsLp1w3alXxcg=; 7:oeBF2lqHqAAcPYbLyJSDFG1uH1bqRBsuP1KNL3y1zslLiwsUkuoxFRBV5Qya976Nl268mbmyrnkPos/OCBt6/WQ0GXaV57fq4bkzQ2GA/026hALyhP92rAtcYqd8EiZh1ZoLtdDk86/WjuBPX0oOuweKVpOQUpi9n73GbWPv7VZwM57iwByTGK0itkFeNLSupAXQahsG8DufFAawnTVTychduAmp3S6ueVE2LQbaGSqDMSSAjhtU5kZgbFGoIN4G
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 6ecb53a1-4b39-4270-8960-08d60d82d906
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB0004;
x-ms-traffictypediagnostic: BN6PR16MB0004:
x-microsoft-antispam-prvs: <BN6PR16MB0004F611DFF8FF37A7345497EA090@BN6PR16MB0004.namprd16.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(50582790962513)(788757137089)(21748063052155)(123452027830198);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(201708071742011)(7699016); SRVR:BN6PR16MB0004; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB0004;
x-forefront-prvs: 077929D941
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(366004)(396003)(136003)(32952001)(199004)(189003)(6246003)(229853002)(66066001)(53936002)(5250100002)(6116002)(74316002)(4326008)(790700001)(5660300001)(2501003)(2906002)(3846002)(316002)(14454004)(97736004)(80792005)(7736002)(93886005)(72206003)(7696005)(25786009)(966005)(110136005)(478600001)(26005)(102836004)(2900100001)(446003)(99286004)(6506007)(105586002)(53546011)(8936002)(8676002)(81156014)(81166006)(5024004)(256004)(53946003)(106356001)(606006)(9326002)(54896002)(55016002)(486006)(236005)(9686003)(6306002)(76176011)(11346002)(68736007)(86362001)(33656002)(6436002)(476003)(186003)(14444005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB0004; H:BN6PR16MB1425.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: W2FTfmlrsztLuD/k7gy2PZsqCSdskblMV8hk4Dq/pxGsZzR7SvCR/Ix/xtmRrlWOdbHsy0ENKHzy9Xwzzq/tYdpq4u6A72kgU4U5/ox7DX4H/hfWF2vwH34Wrtucb4cOHdRD9QgIrkEurBl5fdABZ0kpRl1lXxli1CbrD+T83px011Y4ugetQpUgZmKcC1Qib9dodi52pYw14r43M5BGDYPkaxH91llhKhS2UK3pCLNdiDaNINErfM1/W+0NBGTgQ23VlNc1bgjRN0956x6qI3v6Pilvxm1/jqzB+vKsCL499VUCrFNnuex6kkCgZelFiJgyX+xdvOF3rvl6shXZ9zWVLCII626zXdbKnxgOVOQ=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN6PR16MB1425362E99AE92CB4271B55FEA090BN6PR16MB1425namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6ecb53a1-4b39-4270-8960-08d60d82d906
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2018 07:41:35.6872 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB0004
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0
X-NAI-Spam-Version: 2.3.0.9418 : core <6361> : inlines <6833> : streams <1796879> : uri <2698449>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/rjwhgWKoGlUgKtQs804lsiiH1ug>
Subject: Re: [Dots] some nits and comments about draft-dots-signal-channel-23:
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Aug 2018 07:41:51 -0000

Hi Frank,

Please see inline [TR3]

From: Xialiang (Frank, Network Integration Technology Research Dept) <frank.xialiang@huawei.com>
Sent: Wednesday, August 29, 2018 7:17 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; draft-ietf-dots-signal-channel.authors@ietf.org
Cc: dots@ietf.org
Subject: 答复: some nits and comments about draft-dots-signal-channel-23:


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Hi Tiru,
Please see inline:

发件人: Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
发送时间: 2018年8月28日 21:24
收件人: Xialiang (Frank, Network Integration Technology Research Dept) <frank.xialiang@huawei.com<mailto:frank.xialiang@huawei.com>>; draft-ietf-dots-signal-channel.authors@ietf.org<mailto:draft-ietf-dots-signal-channel.authors@ietf.org>
抄送: dots@ietf.org<mailto:dots@ietf.org>
主题: RE: some nits and comments about draft-dots-signal-channel-23:

Hi Frank,

Please see inline [TR2]

From: Dots <dots-bounces@ietf.org<mailto:dots-bounces@ietf.org>> On Behalf Of Xialiang (Frank, Network Integration Technology Research Dept)
Sent: Tuesday, August 28, 2018 7:29 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com<mailto:TirumaleswarReddy_Konda@McAfee.com>>; draft-ietf-dots-signal-channel.authors@ietf.org<mailto:draft-ietf-dots-signal-channel.authors@ietf.org>
Cc: dots@ietf.org<mailto:dots@ietf.org>
Subject: [Dots] 答复: some nits and comments about draft-dots-signal-channel-23:


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Hi Tiru,
Please see further comments inline:

发件人: Dots [mailto:dots-bounces@ietf.org] 代表 Konda, Tirumaleswar Reddy
发送时间: 2018年8月25日 22:32
收件人: Xialiang (Frank, Network Integration Technology Research Dept) <frank.xialiang@huawei.com<mailto:frank.xialiang@huawei.com>>; draft-ietf-dots-signal-channel.authors@ietf.org<mailto:draft-ietf-dots-signal-channel.authors@ietf.org>
抄送: dots@ietf.org<mailto:dots@ietf.org>
主题: Re: [Dots] some nits and comments about draft-dots-signal-channel-23:

Hi Frank,

Please see inline [TR]

From: Dots <dots-bounces@ietf.org<mailto:dots-bounces@ietf.org>> On Behalf Of Xialiang (Frank, Network Integration Technology Research Dept)
Sent: Friday, August 24, 2018 1:59 PM
To: draft-ietf-dots-signal-channel.authors@ietf.org<mailto:draft-ietf-dots-signal-channel.authors@ietf.org>
Cc: dots@ietf.org<mailto:dots@ietf.org>
Subject: [Dots] some nits and comments about draft-dots-signal-channel-23:


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________

Hi authors,
After once more careful review of this draft, I have the following nits and comments:

Nits:

1.       Last paragraph of section 1: /This is a companion document…/There is a companion document…/


[TR] The line looks correct, DOTS signal channel is a companion document of the DOTS data channel document.


2.       P13, the definition of cuid: /This is a mandatory Uri-Path./ This is a mandatory Uri-Path parameter./

[TR] Yes, will update.


3.       First paragraph in P16: / with indefinite lifetimes./ with indefinite lifetime./


[TR] The line looks correct, “lifetimes” is plural to refer to “mitigations”.



4.       P12: / Uri-Path: "version"/ Uri-Path: "v1"/


5.       P18: / cdid:  Stands for Client Domain IDentifier./ cdid:  Stands for Client Domain Identifier./

[TR] Yes, will fix 4 and 5.




6.       Last paragraph in P21: /The DOTS server couples the DOTS signal channel sessions using the DOTS client identity and optionally the ’cdid’ parameter value, and the DOTS server uses ’mid’ and ’cuid’ Uri-Path parameter values to detect duplicate mitigation requests./ The DOTS server differentiates the DOTS signal channel sessions using the DOTS client identity and optionally the ’cdid’ parameter value. for every DOTS signal channel session, the DOTS server uses ’mid’ Uri-Path parameter values to detect duplicate mitigation requests./

[TR] The above line is added to explain how the DOTS server couples DOTS signal channel sessions from the same DOTS client.
[Frank]: How many signal channel sessions can have between one DOTS client and DOTS server? I assume there only one.

[TR2] The DOTS client can create more than one DOTS signal channel session with the DOTS server, but the draft recommends the client to use a single channel. Please see the following snippet from the Security Considerations Section
<snip>
   A single DOTS signal channel between DOTS agents can be used to
   exchange multiple DOTS signal messages.  To reduce DOTS client and
   DOTS server workload, DOTS clients SHOULD re-use the (D)TLS session.
</snip>
[Frank]: since this is a key point for the whole protocol, I think it’s not enough you only mention it in the Security Consideration Section. Can you add some text to clarify this point in the suitable section more clearly.

[TR3] we can move the above text to section 3 (Design overview), let us know if any other details need to be added.


7.       P22: /This version of the specification forbids ’cuid’ and ’cdid’ (if used) to be returned in a response./This version of the specification forbids ’cuid’ and ’cdid’ (if used) to be returned in a response message body./

[TR] Yes, will update.

Comments:

1.       Last paragraph of P6: only "coaps+tcp" URI scheme is used, no “coaps+udp”?

[TR] No, by default the “coaps” URI scheme defined in RFC7252 is for UDP.
[Frank]: So, do we still need “coaps” URL for the UDP transport?

[TR2] Yes, “coaps” means DTLS-secured CoAP messages exchanged over UDP, please see RFC7252.
[Frank]: why I cannot see the “coaps” URI in the whole document?

[TR3] The doc does not discuss complete URI, hence you don’t see “coaps”.



2.       Please consider including these terminology in section 2: JSON, YANG, CBOR, DER, ASN, SPKI, PSK, SHA, CIDR, TCP, UDP, SCTP, DCCP, IANA, FQDN, URI, ...

[TR] I have not seen any recent RFC adding them to the Terminology. However, we will expand the all the abbreviations (currently only missing for JSON, DER, ASN and PSK).
[Frank]: ok.


3.       Last paragraph of P7: 3..xx Response Codes seems to be not used in this document, delete it?

[TR] Good catch, will delete.



4.       P50: "...time to live values in the CBOR body (Figure 22)", TTL values should not be in the CBOR message body.

[TR] Yes, will remove.



5.       P72: [I-D.ietf-tls-dtls13] should be replaced by [RFC8446]

[TR] No, DTLS 1.3 has not yet become a RFC (see https://tools.ietf.org/html/draft-ietf-tls-dtls13-28)



6.       cuid vs cdid:

1)       Will server-domain DOTS gateways replace the cuid with its own cuid as the new DOTS client?

[TR] No, gateways will not modify or replace cuid.
[Frank]: then, the source ‘cuid’ will reach the final DOTS server, why do we still need the define the ‘cdid’?

[TR2] ‘cdid’ identifies the DOTS client domain whereas ‘cuid’ the DOTS client identity.
[Frank]: so, the main reason for introducing the ‘cdid’ is for differentiating the different DOTS client with the same ‘cuid’ but from the different domain (with different ‘cdid’), not for representing the source DOTS client ?

[TR3] The other reason is ‘cid’ can only be conveyed by the server-domain DOTS gateway and can be trusted by the DOTS server to enforce policies.

If there are multiple DOTS clients in one domain, there should be multiple ‘cuid’ with the only one ‘cdid’?

[TR3] Yes.

Cheers,
-Tiru



2)       Will Server-domain DOTS gateways insert the new cdid to represent the source DOTS client ?

[TR] Yes, but to convey the source DOTS client domain identity.


3)       If the above points are right, I think the third paragraph in P18 is not very clear to clarify them and have space for tuning. And I also think there is a conflict between the 5th and 6th paragraph, since source DOTS clients cannot generate cdid, the DOTS server is impossible to ignore ‘cdid’ attributes that are directly supplied by source DOTS clients.

[TR] I did not get the above comment.



4)       P21: Is “the DOTS client identity” here the same as the ‘cuid’? or another id?

[TR] “DOTS client identity” is explained in page 26
<snip>
As a reminder, a DOTS client
   is identified by its identity (e.g., client certificate, 'cuid') and
   optionally the 'cdid'.
</snip>
[Frank]: so, you mean a “DOTS client identity” can be the client certificate, ‘cuid’ or ‘cdid’ depending on context? If you use this term in other place, how can I know which one it is?

[TR2] No, “DOTS client identity” is ‘cuid’ + ‘cdid’ (‘cdid’ may or may not be present in the mitigation request). The algorithm for generating ‘cuid’ and ‘cdid’ is discussed in the draft and
‘cuid’  can be generated from the DOTS client certificate.

Cheers,
-Tiru

Thanks!

B.R.
Frank