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

[Yoshifumi Nishida <[e-mail]>]

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.


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

> 3:   "DOTS agents SHOULD follow the data transmission guidelines discussed
> >         in Section 3.1.3 of [RFC8085] and control transmission behavior
> by
> >         not sending more than one UDP datagram per round-trip time (RTT)
> to
> >         the peer DOTS agent on average."
> >
> >       ->  How about TCP connections?
>
> [Med] TCP does not have the issue with non-confirmable messages. FWIW,
> RFC8323 states the following:
>
>    The request/response interaction model of CoAP over TCP is the same
>    as CoAP over UDP.  The primary differences are in the message layer.
>    The message layer of CoAP over UDP supports optional reliability by
>    defining four types of messages: Confirmable, Non-confirmable,
>    Acknowledgment, and Reset.
>
>    ...
>
>    Since TCP eliminates the need for the message layer to support
>    reliability, CoAP over reliable transports does not support
>    Confirmable or Non-confirmable message types.
>

I see. Thanks for the clarification.
--
Yoshi