Subject: Tsvart last call review of draft-ietf-dots-signal-channel-31

From: Yoshifumi Nishida via Datatracker <[email-masked]>
Date: Sun, 31 Mar 2019 01:53:13 -0700

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
[email-masked] 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?

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?

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? Do they need a similar principle such as
      limiting window size?

Thanks,
--
Yoshi

---

From: <[email-masked]>
Date: Mon, 1 Apr 2019 06:55:17 +0000

Hi Yoshi, 

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Yoshifumi Nishida via Datatracker [mailto:[email-masked]]
> Envoyé : dimanche 31 mars 2019 10:53
> À : [email-masked]
> Cc : [email-masked]; [email-masked];
> [email-masked]
> Objet : Tsvart last call review of draft-ietf-dots-signal-channel-31
> 

[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). 

>            DTLS over UDPv6? Also, is this logic MAY or SHOULD or don't want

[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.

No restriction is called out in that text. 

The text you quoted is referring to the example in Figure 4. 

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

Do they need a similar principle such as