Re: [Dots] Suresh Krishnan's Discuss on draft-ietf-dots-signal-channel-31: (with DISCUSS and COMMENT)

[<[e-mail]>]

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Suresh Krishnan via Datatracker [mailto:[e-mail]]
> Envoyé : mercredi 1 mai 2019 05:07
> À : The IESG
> Cc : [e-mail]; Liang Xia; dots-
> [e-mail]; [e-mail]; [e-mail]
> Objet : Suresh Krishnan's Discuss on draft-ietf-dots-signal-channel-31: (with
> DISCUSS and COMMENT)
> 
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-dots-signal-channel-31: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This should be easy to clear up, but I would like to understand why this
> document needs to restate the motivation and describe the algorithm for happy
> eyeballs instead of simply stating that hosts should use RFC8305

[Med] We adopted this elaborated approach because there are specifics to the DOTS case that are called out in the text, e.g.,
* probing to migrate the connection
* caching (used to be in HE v1)

Also, unlike RFC8305:
* we don't cancel all other connections upon establishment of one connection.
* we don't forbid all attempts to be sent simultaneously. 

All these details are described in the text. 

 and then
> specify that UDP must be tried before TCP in each of the address families. If
> you do want to specify the whole algorithm here it needs to be more specific
> than "in a manner similar to the Happy Eyeballs mechanism" as it is not clear
> where it is similar (and where it will differ). It also looks like the
> example
> flow in Figure 4 is not consistent with the description before (TCP+IPv6
> before
> UDP+IPv4)

[Med] The text says the following: 

   In reference to Figure 4, the DOTS client sends two TCP SYNs and two
   DTLS ClientHello messages at the same time over IPv6 and IPv4.
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^     

Ben suggested in his review to add annotations to Figure 4 but we didn't because we though this is redundant with the above text.

Will add annotations to Figure 4.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> * Section 7.3
> 
> This text is wrong and needs to be removed
> 
> "IP packets whose size does not exceed 576 bytes should never need to be
> fragmented"
> 
> RFC791 only requires all hosts to be prepared to accept datagrams of up to
> 576 octets.
> 

[Med] Done.