Re: [Dots] About modification of draft-ietf-dots-use-cases-18

kaname nishizuka <kaname@nttv6.jp> Thu, 25 July 2019 21:51 UTC

Return-Path: <kaname@nttv6.jp>
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 920921202B5; Thu, 25 Jul 2019 14:51:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nttv6.jp
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 lCpYHovApxzX; Thu, 25 Jul 2019 14:51:34 -0700 (PDT)
Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8FAA2120299; Thu, 25 Jul 2019 14:51:34 -0700 (PDT)
Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 1402625F6BD; Fri, 26 Jul 2019 06:51:33 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nttv6.jp; s=20180820; t=1564091493; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pPzIwVZiAJNmnXy/9hNOyQK/Aj8ehby9YLcBB9O31N8=; b=pMqWnOf7K/dC5LG0Hxd2Vl2ZlsY3uTxvmZRIIZO8gqCw8cTyRWKmhuyn00IeZAY2VO9ecn c+jkIz2N6rdOXxzCpWrTli7KgWLjthaMg7XY8e9CEeKQg45WJc8cUeBaRJFO4AxNtDur2T qhYBt6Id+wiecQut9Cj85NWgm/s2Cnw=
Received: from dhcp-9bef.meeting.ietf.org (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 2085D7634FC; Fri, 26 Jul 2019 06:51:31 +0900 (JST)
To: =?UTF-8?Q?T=c3=b6ma_Gavrichenkov?= <ximaera@gmail.com>, H Y <yuuhei.hayashi@gmail.com>
Cc: "draft-ietf-dots-use-cases@ietf.org" <draft-ietf-dots-use-cases@ietf.org>, dots <dots@ietf.org>
References: <CAA8pjUM-5QPQZNfFAwG_1rQ02-Hy7pDjyBn2fZ1RRank+UaHRw@mail.gmail.com> <CALZ3u+ZGPwypx4F-a1aX9DKBpC9B-Ls_D1ZgnH4am-rd6tx6gA@mail.gmail.com>
From: kaname nishizuka <kaname@nttv6.jp>
Message-ID: <20c22342-006f-12af-2244-e84a30fd72f5@nttv6.jp>
Date: Fri, 26 Jul 2019 06:51:33 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CALZ3u+ZGPwypx4F-a1aX9DKBpC9B-Ls_D1ZgnH4am-rd6tx6gA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Authentication-Results: guri.nttv6.jp; spf=pass smtp.mailfrom=kaname@nttv6.jp
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/YHYhxLzLozLQzlYe0rFYEq4kf6g>
Subject: Re: [Dots] About modification of draft-ietf-dots-use-cases-18
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: Thu, 25 Jul 2019 21:51:42 -0000

Yes, I do believe.
I heard from Yuhei that this additional section stems from operator's needs, and also from view point of an implementer it is worth to be mentioned.
So I'm happy with including it.

thanks,
Kaname


On 2019/07/26 5:07, Töma Gavrichenkov wrote:
> Peace,
>
> On Thu, Jul 25, 2019 at 10:28 PM H Y <yuuhei.hayashi@gmail.com>; wrote:
>> I just appended the below sentence to 3.3. DDoS Orchestration of
>> draft-ietf-dots-use-cases-18.
> IMO this, from the architectural point of view, is quite an obvious
> use case which doesn't have a lot to do with orchestration itself,
> because it is mostly covered (in a different set of words) in 3.1.
>
> That being said, I'm personally fine with incorporating this into the
> draft if Kaname believes this provides a better guidance for
> implementers.
>
> --
> Töma