Re: [Dots] Tsvart last call review of draft-ietf-dots-signal-channel-31

[Yoshifumi Nishida <[e-mail]>]

Hi Med,

On Tue, Apr 2, 2019 at 11:35 PM <[e-mail]> wrote:

> Hi Yoshi,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Yoshifumi Nishida [mailto:[e-mail]]
> *Envoyé :* mercredi 3 avril 2019 00:02
> *À :* BOUCADAIR Mohamed TGI/OLN
> *Cc :* Yoshifumi Nishida; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> *Objet :* Re: Tsvart last call review of draft-ietf-dots-signal-channel-31
>
>
>
> HI Med,
>
>
>
> Thanks for the reply. I put my comments in lines.
>
>
>
> On Sun, Mar 31, 2019 at 11:55 PM <[e-mail]> wrote:
>
> Hi Yoshi,
>
> Thank you for the review.
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Yoshifumi Nishida via Datatracker [mailto:[e-mail]]
> > Envoyé : dimanche 31 mars 2019 10:53
> > À : [e-mail]
> > Cc : [e-mail]; [e-mail];
> > [e-mail]
> > Objet : Tsvart last call review of draft-ietf-dots-signal-channel-31
> >
> > Reviewer: Yoshifumi Nishida
> > Review result: Almost Ready
> >
> > This document has been reviewed as part of the transport area review
> team's
> > ongoing effort to review key IETF documents. These comments were written
> > primarily for the transport area directors, but are copied to the
> document's
> > authors and WG to allow them to address any issues raised and also to the
> > IETF
> > discussion list for information.
> >
> > When done at the time of IETF Last Call, the authors should consider this
> > review as part of the last-call comments they receive. Please always CC
> > [e-mail] if you reply to or forward this review.
> >
> > Summary: This document is almost ready for publication, but it will be
> better
> > to clarify the following points.
> >
> > 1:   "it is out of scope of this document to specify the behavior to be
> > followed by a DOTS client to send DOTS requests when multiple
> >         DOTS servers are provisioned."
> >
> >       I'm not sure why it is out of scope. Does it bring a certain
> > complexities
> >       to the protocol?
> >      Or, does it simply mean it is up to implementations?
>
> [Med] This is because of specific considerations such as those discussed
> in draft-ietf-dots-multihoming. We don't want to overload the base spec
> with such considerations (discussed in separate documents). The same
> approach is followed for server discovery
> (draft-ietf-dots-server-discovery).
>
>
>
> Got it. I think it would be useful for readers to mention it in the draft.
>
>
>
> [Med] I updated the text as follows :
>
>
>
>    Likewise, it is out of scope of this document to specify the behavior
>
>    to be followed by a DOTS client to send DOTS requests when multiple
>
>    DOTS servers are provisioned (e.g., contact all DOTS servers, select
>
>    one DOTS server among the list).  Such behavior is specified in other
>
>                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>    documents (e.g.,  [I-D.ietf-dots-multihoming]).
>
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>

WFM. Thanks for the updates!


>
>
>
>
> > 2:   "The DOTS client periodically repeats the mechanism to discover
> whether
> > DOTS signal
> >         channel messages with DTLS over UDP becomes available from the
> DOTS
> >         server.."
> >
> >        -> Does this mean DOTS clients will not repeat this when it
> already
> > has
> >        DTLS over UDP connection?
> >            What about if the client has DTLS over UDPv4? Does it try to
> check
> >            DTLS over UDPv6? Also, is this logic MAY or SHOULD or don't
> want
> > to
> >            specify?
>
> [Med] The client will retry when the cache flushes out:
>
>
>    Note that the DOTS client after successfully establishing a
>    connection MUST cache information regarding the outcome of each
>    connection attempt for a specific time period, and it uses that
>    information to avoid thrashing the network with subsequent attempts.
>
>
>
> OK, but if you retry anyway after a certain time, why do you need to cache
> the results?
>
>
>
> [Med] “to avoid thrashing the network with subsequent attempts” as the
> text says. Also, caching avoids the inconvenience of selection during
> attack times. Typically, the client executes the HE procedure when it
> initializes and uses the outcome of the procedure for subsequent DOTS
> signal exchanges during a certain period. Please refer to this text in the
> draft:
>

Hmm. let's say the results of the happy eyeballs was TCP over IPv4 (just
like the figure 4) and the client cache the info.
After certain period of time, the client will do happy eyeball again
because other better connections might be available . But, in this case,
how the cached info will be used?

It seems that an implementation that doesn't cache the info at all and does
happy eyeballs at every 10 hours won't be allowed in this draft.

Thanks,
--
Yoshi

>