[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> Thu, 27 June 2019 02:14 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 0D4F41203D1 for <dots@ietfa.amsl.com>; Wed, 26 Jun 2019 19:14:26 -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 bBw5DDDh2xDV for <dots@ietfa.amsl.com>; Wed, 26 Jun 2019 19:14:23 -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 C927A120288 for <dots@ietf.org>; Wed, 26 Jun 2019 19:14:22 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 133D4139B5565C5A6646 for <dots@ietf.org>; Thu, 27 Jun 2019 03:14:21 +0100 (IST)
Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Jun 2019 03:14:20 +0100
Received: from DGGEMM511-MBX.china.huawei.com ([169.254.1.140]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0439.000; Thu, 27 Jun 2019 10:10:37 +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/vRHMZHXNOgChEGMQABkhPfAAHE/FYABMGPLg
Date: Thu, 27 Jun 2019 02:10:36 +0000
Message-ID: <C02846B1344F344EB4FAA6FA7AF481F13E7B4518@dggemm511-mbx.china.huawei.com>
References: <C02846B1344F344EB4FAA6FA7AF481F13E7AC66A@dggemm511-mbx.china.huawei.com> <787AE7BB302AE849A7480A190F8B93302EAAC4F3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <C02846B1344F344EB4FAA6FA7AF481F13E7B115A@dggemm511-mbx.china.huawei.com> <787AE7BB302AE849A7480A190F8B93302EAAD070@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAAD070@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/fARzPen7LK-QFJhieIESpfmPLzo>
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: Thu, 27 Jun 2019 02:14:26 -0000

Hi Med and authors,
Please see inline:




-----邮件原件-----
发件人: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] 
发送时间: 2019年6月25日 21:53
收件人: 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, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Xialiang (Frank, Network Standard & Patent Dept) 
> [mailto:frank.xialiang@huawei.com]
> Envoyé : mardi 25 juin 2019 02:31
> À : 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 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.

[Med] I agree. It is fine as far as we declare address selection out of scope. Will remove that sentence. 

> 
> >     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?

[Med] That is what a server following the spec will do. We are catching a misbehaving one. 


[Frank]: following which spec? In theory, I am just confusing why the server have to send back multiple instances?

> 
>  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.".

[Med] This is similar to the previous comment. The intent of the text you quoted is to cover the case of a (misbehaving) server which returns more than one instance. 

[Frank]: similarly, we need to confirm whether this kind of misbehaving will sure happen?

> 
> >     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

[Frank]: well, I still reserve my opinion.
> 
> >     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.

[Med] What I meant is that the IP address(es) will be obtained by following the procedure in RFC3958. A Sample sequence diagram is available at: https://tools.ietf.org/html/rfc3958#section-4.6 

[Frank]: I got your point. Let me rephrase my concern: can you confirm these 2 DNS service resolution methods have the totally same process, so that using one exemplar process is enough to cover two?


B.R.
Frank

> 
> 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-disco
> > > ve
> > > 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