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

[Benjamin Kaduk <[e-mail]>]

Hi Med,

I'm not sure that's fully responsive to Suresh's point.  Yes, we need to
document clearly what we are doing (and how it differs from RFC 8305 is a
good rhetorical mechanism for doing so), but I think the point was that we
also need to justify why the existing solution does not work for our use
case.  That justification may or may not need to be in the resulting RFC,
but it does need to exist in order for the document to pass IESG
evaluation.

Thanks,

Ben

On Fri, May 03, 2019 at 09:25:30AM +0000, [e-mail] wrote:
> Suresh, 
> 
> We rearranged the text to better indicate where DOTS HE differs from 8305. You can check the changes at:
> 
> Txt: https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/draft-ietf-dots-signal-channel-31.txt 
> Diff: https://github.com/boucadair/draft-ietf-dots-signal-channel/blob/master/wdiff%20draft-ietf-dots-signal-channel-31.txt%20draft-ietf-dots-signal-channel-31.pdf 
> 
> If any further change/clarification is needed, please let me know. 
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : [e-mail] [mailto:[e-mail]]
> > Envoyé : jeudi 2 mai 2019 08:36
> > À : Suresh Krishnan; The IESG
> > Cc : [e-mail]; Liang Xia; dots-
> > [e-mail]; [e-mail]
> > Objet : RE: Suresh Krishnan's Discuss on draft-ietf-dots-signal-channel-31:
> > (with DISCUSS and COMMENT)
> > 
> > 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.