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

[<[e-mail]>]

Hi Franck, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Xialiang (Frank, Network Standard & Patent Dept)
> [mailto:[e-mail]]
> Envoyé : jeudi 27 juin 2019 04:11
> À : 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 Med and authors,
> Please see inline:
> 
> 
> 
> 
> -----邮件原件-----
> 发件人: [e-mail] [mailto:[e-mail]]
> 发送时间: 2019年6月25日 21:53
> 收件人: 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,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Xialiang (Frank, Network Standard & Patent Dept)
> > [mailto:[e-mail]]
> > Envoyé : mardi 25 juin 2019 02:31
> > À : 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 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.
> 
> [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:[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-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
> > > > [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