[Dots] 答复: comments for this document as contributor://答复: I-D Action: draft-ietf-dots-server-discovery-03.txt

"Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com> Tue, 25 June 2019 00:30 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 24DF81201F2 for <dots@ietfa.amsl.com>; Mon, 24 Jun 2019 17:30:51 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 omnTJTIqfwPx for <dots@ietfa.amsl.com>; Mon, 24 Jun 2019 17:30:48 -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 D8B3A12021D for <dots@ietf.org>; Mon, 24 Jun 2019 17:30:47 -0700 (PDT)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id F027DB732095CE08E223 for <dots@ietf.org>; Tue, 25 Jun 2019 01:30:43 +0100 (IST)
Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 25 Jun 2019 01:30:43 +0100
Received: from DGGEMM511-MBX.china.huawei.com ([169.254.1.140]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0439.000; Tue, 25 Jun 2019 08:30:36 +0800
From: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: =?utf-8?B?Y29tbWVudHMgZm9yIHRoaXMgZG9jdW1lbnQgYXMgY29udHJpYnV0b3I6Ly8=?= =?utf-8?B?562U5aSNOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtc2VydmVyLWRp?= =?utf-8?Q?scovery-03.txt?=
Thread-Index: AdUoAc6D6bAbWctJRc2/vRHMZHXNOgChEGMQABkhPfA=
Date: Tue, 25 Jun 2019 00:30:36 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F13E7B115A@dggemm511-mbx.china.huawei.com>
References: <C02846B1344F344EB4FAA6FA7AF481F13E7AC66A@dggemm511-mbx.china.huawei.com> <787AE7BB302AE849A7480A190F8B93302EAAC4F3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAAC4F3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/tVoyVC3glO57xQlz3jM80WQQIYs>
Subject: [Dots] =?utf-8?b?562U5aSNOiBjb21tZW50cyBmb3IgdGhpcyBkb2N1bWVu?= =?utf-8?b?dCBhcyBjb250cmlidXRvcjovL+etlOWkjTogSS1EIEFjdGlvbjogZHJhZnQt?= =?utf-8?q?ietf-dots-server-discovery-03=2Etxt?=
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: Tue, 25 Jun 2019 00:30:51 -0000

Hi Med,
Please see inline:

-----邮件原件-----
发件人: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] 
发送时间: 2019年6月24日 20:40
收件人: Xialiang (Frank, Network Standard & Patent Dept) <frank.xialiang@huawei.com>;
抄送: dots@ietf.org
主题: RE: comments for this document as contributor://答复: I-D Action: draft-ietf-dots-server-discovery-03.txt

Hi Franck, 

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Xialiang (Frank, Network Standard & Patent Dept) 
> [mailto:frank.xialiang@huawei.com]
> Envoyé : vendredi 21 juin 2019 10:20
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : dots@ietf.org
> Objet : comments for this document as contributor://答复: I-D Action:
> draft-ietf-dots-server-discovery-03.txt
> 
> Hi authors,
> I have several comments as contributor below:
> 
> 1. nits
>     Section 1:
>         s/The discovery methods can also used by a DOTS server to 
> locate.../ The discovery methods can also be used by a DOTS server to 
> locate.../
>         s/ [I-D.ietf-netconf-zerotouch]/[RFC8527]/
>     title section 5: s/DHCP Options for DOTS/ DHCP Options for DOTS 
> Agent Discovery/
>     section 5.1.1: s/ The DHCPv6 DOTS option/ The DHCPv6 DOTS 
> Reference Identifier option/
>     section 5.1.2: s/ The DHCPv6 DOTS option/ The DHCPv6 DOTS Address 
> option/
>     section 5.2.1: s/ The DHCPv4 DOTS option/ The DHCPv4 DOTS 
> Reference Identifier option/
>     section 5.2.2: s/ The DHCPv4 DOTS option/ The DHCPv4 DOTS Address 
> option/
> 

[Med] Fixed. 

> 2. comments:
>     1) In section 1, I don't see any relation of happy eyeball with 
> your proposed dots agent discovery mechanism, it not so necessary to 
> mention it;

[Med] This is to warrant that, when multiple addresses are available such as both ipv4 and ipv6, this I-D does not specify how address selection is made. A pointer where such procedure is defined is helpful for the reader.

[Frank]: My point is: in theory, discovery process is ahead of address selection process, they have no overlapping.

>     2) In section 4, " DOTS clients will prefer information received 
> from the discovery methods in the order listed. ": in what kind of order?

[Med] The order of appearance in the bullet list. 

>     3) For section 5.1.3 and section 5.2.3, there seems to be some 
> confusions and conflictions about these points: what is the goal of 
> returning more than one instance of OPTION_V6_DOTS if must only use 
> the first instance?

[Med] This text is to describe the behavior when the server returns more while the client expects to receive only one. An alternative is to discard such messages, but it is likely that the client won't be configured. This behavior is more tolerant to misbehaving servers. 

[Frank]: why not just return one instance of OPTION_V6_DOTS?

 Does one DOTS Reference Identifier Option include one or
> multiple dots-agent-name?

[Med] Only one name is allowed: 

   o  dots-agent-name: A fully qualified domain name of the peer DOTS
      agent.

[Frank]: but you have said in draft: " If the DHCP client receives OPTION_V6_DOTS_RI only, but OPTION_V6_DOTS_RI option contains more than one name, as distinguished by the presence of multiple root labels, the DHCP client MUST use only the first name.".

>     4) In section 5.2.1, will figure 5 be more appropriate as figure 3?

[Med] I don't think so. Figure 3 does the job. 

[Frank]: no, I mean Figure 3 is better than Figure 5

>     5) For section 6--DNS service resolution , this section does not 
> clarify the process and details about how to get DOTS agent IP based 
> on the retrieved DOTS agent name?

[Med] This is based on normal S-NAPTR lookups. Which further information you think is missing? 

[Frank]: If I understand correctly, there are 2 ways of DNS service resolution, one is by DNS domain name, the other is by DOTS agent name. The section 6 is all about the former, no content about the latter one.

B.R.
Frank

>     6) Section 7 (DNS-SD) is very short, can you clarify briefly what 
> is the essential difference between this mechanism and previous DNS 
> service resolution mechanism?

[Med] The procedure defined in RFC6763 is followed. This section defines the required information for DOTS context. We don't need to repeat the details that are already covered in 6763. 

>     7) Is it possible to list the pro & con, or at least the related 
> constraints for each discovery mechanisms at the end of the document? 
> I think it's useful for reader in the real implementation.

[Med] Actually, this will depend on the deployment context as discussed in Section 3 rather than a purely technical pro&cons of each method. For example, a CPE which embeds a DOTS client is likely to use the same provisioning method to discover the peer DOTS agent. Such devices are usually using DHCP for such matters. Leveraging DHCP seems natural. Please check section 3.

> 
> Thanks!
> 
> B.R.
> Frank
> 
> 
> -----邮件原件-----
> 发件人: Dots [mailto:dots-bounces@ietf.org] 代表
> mohamed.boucadair@orange.com
> 发送时间: 2019年5月31日 17:19
> 收件人: dots@ietf.org
> 主题: Re: [Dots] I-D Action: draft-ietf-dots-server-discovery-03.txt
> 
> Hi all,
> 
> The main change in this version is to integrate call-home considerations.
> 
> We do think this version is stable enough for a WGLC.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part 
> > de internet-drafts@ietf.org Envoyé : vendredi 31 mai 2019 11:10 À :
> > i-d-announce@ietf.org Cc : dots@ietf.org Objet : I-D Action:
> > draft-ietf-dots-server-discovery-03.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> > This draft is a work item of the DDoS Open Threat Signaling WG of 
> > the IETF.
> >
> >         Title           : Distributed-Denial-of-Service Open Threat
> > Signaling (DOTS) Server Discovery
> >         Authors         : Mohamed Boucadair
> >                           Tirumaleswar Reddy
> > 	Filename        : draft-ietf-dots-server-discovery-03.txt
> > 	Pages           : 22
> > 	Date            : 2019-05-31
> >
> > Abstract:
> >    It may not be possible for a network to determine the cause for an
> >    attack, but instead just realize that some resources seem to be under
> >    attack.  To fill that gap, Distributed-Denial-of-Service Open Threat
> >    Signaling (DOTS) allows a network to inform a DOTS server that it is
> >    under a potential attack so that appropriate mitigation actions are
> >    undertaken.
> >
> >    This document specifies mechanisms to configure DOTS clients with
> >    DOTS servers.  The discovery procedure also covers the DOTS Signal
> >    Channel Call Home.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/
> >
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-dots-server-discovery-03
> > https://datatracker.ietf.org/doc/html/draft-ietf-dots-server-discove
> > ry
> > -03
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-server-discovery-0
> > 3
> >
> >
> > Please note that it may take a couple of minutes from the time of 
> > submission until the htmlized version and diff are available at 
> > tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > I-D-Announce@ietf.org
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots