[Dots] Hi, authors, 3 questions on draft-hayashi-dots-dms-offload-usecase-01:

"Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com> Fri, 12 July 2019 03:09 UTC

Return-Path: <frank.xialiang@huawei.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 01ADD120089; Thu, 11 Jul 2019 20:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ch-51kvOfkoi; Thu, 11 Jul 2019 20:09:57 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 BAF99120052; Thu, 11 Jul 2019 20:09:56 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 54D83F74E4EC4589453D; Fri, 12 Jul 2019 04:09:54 +0100 (IST)
Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 12 Jul 2019 04:09:53 +0100
Received: from DGGEMM511-MBX.china.huawei.com ([169.254.1.140]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0439.000; Fri, 12 Jul 2019 11:08:16 +0800
From: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
To: "draft-hayashi-dots-dms-offload-usecase.authors@ietf.org" <draft-hayashi-dots-dms-offload-usecase.authors@ietf.org>
CC: "dots@ietf.org" <dots@ietf.org>, Valery Smyslov <valery@smyslov.net>
Thread-Topic: Hi, authors, 3 questions on draft-hayashi-dots-dms-offload-usecase-01:
Thread-Index: AdU4Xd5vj9xW+DVwTo2s5d/iB7L+dA==
Date: Fri, 12 Jul 2019 03:08:15 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F13E7C878E@dggemm511-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.134.159.76]
Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F13E7C878Edggemm511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/ZsgFeSU_YATvzddAAPru3wlTiHo>
Subject: [Dots] Hi, authors, 3 questions on draft-hayashi-dots-dms-offload-usecase-01:
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 12 Jul 2019 03:09:59 -0000

Hi authors,
I have reviewed this new version and have 3 questions as below:

1.      I see your proposed offload use case as an variant of DOTS Orchestration use case (section 3.3 of draft-ietf-dots-use-cases-18). If so, what is your propose for this part of content? Do you want to improve the existing DOTS use cases WG draft with your addition?

2.      Right now, DOTS protocol defines sending DOTS request via signal channel, do you propose to send it via data channel in some situation? If so, I personally disagree with it, since we originally define signal channel and data channel for different functionalities & messages, we can not send any DOTS messages over wrong channel, like: DOTS request via data channel.

3.      In addition to extended offload use case content, I do not see any new protocol, message or attribute extension comparing to the existing defined DOTS protocols, the left content are just some examples about how you use the existing DOTS protocol for your offload use case. So, what do you want DOTS WG to do for this draft, since there are no new thing here? And be careful using signal channel call home for your use case, since it is a special mechanism for near source attack mitigation with DOTS server create TLS connection with DOTS client, which I don't think it's very suitable for your case.

Thanks!

B.R.
Frank