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

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Fri, 21 Jun 2019 08:20:05 +0000

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/

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;
    2) In section 4, " DOTS clients will prefer information received from the discovery methods in the order listed. ": in what kind of order?
    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? Does one DOTS Reference Identifier Option include one or multiple dots-agent-name?
    4) In section 5.2.1, will figure 5 be more appropriate as figure 3?
    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?
    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?
    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.

Thanks!

B.R.
Frank

-----邮件原件-----
发件人: Dots [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2019年5月31日 17:19
收件人: [email-masked]
主题: 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:[email-masked]] De la part de 
> [email-masked] Envoyé : vendredi 31 mai 2019 11:10 À : 
> [email-masked] Cc : [email-masked] 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-discovery
> -03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-server-discovery-03
> 
> 
> 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
> [email-masked]
> 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
[email-masked]
https://www.ietf.org/mailman/listinfo/dots

---

From: <[email-masked]>
Date: Mon, 24 Jun 2019 12:39:34 +0000

Hi Franck, 

Thank you for the comments. 

Please see inline. 

Cheers,
Med

> De : Xialiang (Frank, Network Standard & Patent Dept)
> [mailto:[email-masked]]
> Envoyé : vendredi 21 juin 2019 10:20
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : [email-masked]
> Objet : comments for this document as contributor://答复: I-D Action:
>         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.../

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

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

 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.

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

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

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

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Tue, 25 Jun 2019 00:30:36 +0000

Hi Med,
Please see inline:

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

Hi Franck, 

Please see inline. 

Cheers,
Med

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

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

> returning more than one instance of OPTION_V6_DOTS if must only use 
> the first instance?

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

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

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

> clarify the process and details about how to get DOTS agent IP based 
> on the retrieved DOTS agent name?

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

> constraints for each discovery mechanisms at the end of the document? 
> I think it's useful for reader in the real implementation.

> > De : I-D-Announce [mailto:[email-masked]] De la part 
> > de [email-masked] Envoyé : vendredi 31 mai 2019 11:10 À :
> > This draft is a work item of the DDoS Open Threat Signaling WG of 
> > the IETF.
> >

---

From: <[email-masked]>
Date: Tue, 25 Jun 2019 13:52:46 +0000

Hi Franck, 

Please see inline. 

Cheers,
Med

> Envoyé : mardi 25 juin 2019 02:31
> Objet : 答复: comments for this document as contributor://答复: I-D Action:
> [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. 

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

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

> [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]: 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 

> [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.
> 
> [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
> >
> >
> > -----邮件原件-----

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Thu, 27 Jun 2019 02:10:36 +0000

Hi Med and authors,
Please see inline:

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2019年6月25日 21:53
收件人: Xialiang (Frank, Network Standard & Patent Dept) <[email-masked]>
抄送: [email-masked]
主题: RE: comments for this document as contributor://答复: I-D Action: draft-ietf-dots-server-discovery-03.txt

Hi Franck, 

Please see inline. 

Cheers,
Med

> > Envoyé : vendredi 21 juin 2019 10:20 À : BOUCADAIR Mohamed TGI/OLN 
> > Cc : [email-masked] Objet : comments for this document as 
> > contributor://答复: I-D Action:
> > locate.../ The discovery methods can also be used by a DOTS server 
> > to locate.../
> [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.
> 

> [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]: following which spec? In theory, I am just confusing why the server have to send back multiple instances?

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

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

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

[Frank]: well, I still reserve my opinion.

[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.
> 
> [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
> >
> >
> > -----邮件原件-----
> > > De : I-D-Announce [mailto:[email-masked]] De la 
> > > part de [email-masked] Envoyé : vendredi 31 mai 2019 11:10 À :
> > >    Signaling (DOTS) allows a network to inform a DOTS server that 
> > > it
> is
> > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-server-disco
> > > ve
> > > ry
> > > -03
> > >
> > > https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-server-discovery
> > > -0
> > > 3
> > >
> > >

---

From: <[email-masked]>
Date: Thu, 27 Jun 2019 08:56:30 +0000

Hi Franck, 

Please see inline. 

Cheers,
Med

> Envoyé : jeudi 27 juin 2019 04:11
> [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.

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

[Med] That is an error that can occur because of misconfiguration. Better to have clients ready to handle it. 

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

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