Last Call Review of draft-ietf-dots-signal-channel-31
review-ietf-dots-signal-channel-31-tsvart-lc-nishida-2019-03-31-00
| Request | Review of | draft-ietf-dots-signal-channel |
|---|---|---|
| Requested rev. | no specific revision (document currently at 41) | |
| Type | Last Call Review | |
| Team | Transport Area Review Team (tsvart) | |
| Deadline | 2019-03-19 | |
| Requested | 2019-03-05 | |
| Authors | Tirumaleswar Reddy.K, Mohamed Boucadair, Prashanth Patil, Andrew Mortensen, Nik Teague | |
| Draft last updated | 2019-03-31 | |
| Completed reviews |
Tsvart Last Call review of -31 by Yoshifumi Nishida
(diff)
Secdir Last Call review of -30 by Stephen Farrell (diff) Genart Last Call review of -30 by Ines Robles (diff) Opsdir Last Call review of -31 by Menachem Dodge (diff) Secdir Telechat review of -31 by Stephen Farrell (diff) |
|
| Assignment | Reviewer | Yoshifumi Nishida |
| State | Completed | |
| Review | review-ietf-dots-signal-channel-31-tsvart-lc-nishida-2019-03-31 | |
| Reviewed rev. | 31 (document currently at 41) | |
| Review result | Almost Ready | |
| Review completed: | 2019-03-31 |
Review
review-ietf-dots-signal-channel-31-tsvart-lc-nishida-2019-03-31
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
tsv-art@ietf.org 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