Re: [Dots] comments for this document as contributor://答复: I-D Action: draft-ietf-dots-server-discovery-03.txt
<mohamed.boucadair@orange.com> Thu, 27 June 2019 08:56 UTC
Return-Path: <mohamed.boucadair@orange.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 26024120152 for <dots@ietfa.amsl.com>; Thu, 27 Jun 2019 01:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 hUm5Zpe0k_DB for <dots@ietfa.amsl.com>; Thu, 27 Jun 2019 01:56:49 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9AC6120122 for <dots@ietf.org>; Thu, 27 Jun 2019 01:56:48 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 45ZDKC3X4Vz114L; Thu, 27 Jun 2019 10:56:31 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 45ZDKC2q4tz8sYk; Thu, 27 Jun 2019 10:56:31 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM31.corporate.adroot.infra.ftgroup ([fe80::34b6:11d0:147f:6560%21]) with mapi id 14.03.0439.000; Thu, 27 Jun 2019 10:56:31 +0200
From: mohamed.boucadair@orange.com
To: "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: comments for this document as contributor://答复: I-D Action: draft-ietf-dots-server-discovery-03.txt
Thread-Index: AdUoAc6D6bAbWctJRc2/vRHMZHXNOgChEGMQABkhPfAAHE/FYABMGPLgAA4B18A=
Date: Thu, 27 Jun 2019 08:56:30 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EAAE8ED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
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> <C02846B1344F344EB4FAA6FA7AF481F13E7B4518@dggemm511-mbx.china.huawei.com>
In-Reply-To: <C02846B1344F344EB4FAA6FA7AF481F13E7B4518@dggemm511-mbx.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/w7Alok6vmK3SiL3Tofozq7fUkiQ>
Subject: Re: [Dots] comments for this document as contributor://答复: I-D Action: draft-ietf-dots-server-discovery-03.txt
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 08:56:52 -0000
Hi Franck, Please see inline. Cheers, Med > -----Message d'origine----- > De : Xialiang (Frank, Network Standard & Patent Dept) > [mailto:frank.xialiang@huawei.com] > Envoyé : jeudi 27 juin 2019 04:11 > À : 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 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? > [Med] I meant draft-ietf-dots-server-discovery. The case we are catching is a misconfigured server which sent multiple options while it should not. The client has to deal with that error: * it may consider it as an error: it will discard the message. The client won't have access the service till the server is fixed. * it may tolerate that by making use of the first occurrence and ignore the others. The client will access the service. > > > > 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? > [Med] That is an error that can occur because of misconfiguration. Better to have clients ready to handle it. > > > > > 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. [Med] Figure 5 shows the format of the DHCP option. The internal structure of the name is the same as in Figure 3: - The description of Figure 5 says that the format of the name is done according to Section 10 of [RFC8415], which relies upon rfc1035#section-3.1. - Figure 3 is a representation of the rfc1035#section-3.1 text: "Domain names in messages are expressed in terms of a sequence of labels. Each label is represented as a one octet length field followed by that number of octets." > > > > > 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? > [Med] Which "2 service resolution methods" are you referring to? Thanks. > > 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
- [Dots] comments for this document as contributor:… Xialiang (Frank, Network Standard & Patent Dept)
- Re: [Dots] comments for this document as contribu… mohamed.boucadair
- [Dots] 答复: comments for this document as contribu… Xialiang (Frank, Network Standard & Patent Dept)
- Re: [Dots] comments for this document as contribu… mohamed.boucadair
- [Dots] 答复: comments for this document as contribu… Xialiang (Frank, Network Standard & Patent Dept)
- Re: [Dots] comments for this document as contribu… mohamed.boucadair