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

["Xialiang (Frank, Network Standard & Patent Dept)" <[e-mail]>]

Hi Med,
Please see inline:

-----邮件原件-----
发件人: [e-mail] [mailto:[e-mail]] 
发送时间: 2019年6月24日 20:40
收件人: Xialiang (Frank, Network Standard & Patent Dept) <[e-mail]>
抄送: [e-mail]
主题: 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:[e-mail]]
> Envoyé : vendredi 21 juin 2019 10:20
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [e-mail]
> 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:[e-mail]] 代表
> [e-mail]
> 发送时间: 2019年5月31日 17:19
> 收件人: [e-mail]
> 主题: 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:[e-mail]] De la part 
> > de [e-mail] Envoyé : vendredi 31 mai 2019 11:10 À :
> > [e-mail] Cc : [e-mail] 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
> > [e-mail]
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots