Re: Tsvart last call review of draft-ietf-dots-requirements-16

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi, all,
The following boilerplate was supposed to have been inserted automatically…
Joe

——
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@xxxxxxxx if you reply to or forward this review.
---

On Nov 17, 2018, at 5:39 PM, Joseph Touch <touch@xxxxxxxxxxxxxx> wrote:

Reviewer: Joseph Touch
Review result: Ready with Issues

Transport issues:
- The GEN requirements refer to signal and data channels; it should be more
clear that these would be transport associations or connections, not
necessarily separate port assignments - GEN-03 recommends transports that avoid
HOL blocking, but that blocking can occur at any protocol layer (e.g., when
using TCP as a tunneling layer or at the application layer) - SIG-001 – PLPMTUD
should be used instead of PMTUD; PMTUD (relying on ICMP, which is often blocked
and remains insecure) should be avoided. The PMTU of 1280 is relevant only for
IPv6. The use of 576 should be more clearly indicated as applying only to IPv4.
(note there is emerging PLPMTUD for UDP). - SIG-004 should address the use of
TCP keepalives for TCP connections as a way to achieve heartbeats. - SIG-004 is
self-contradictory, at first claiming that agents SHOULD avoid termination due
to heartbeat loss then later saying they MAY use heartbeat absence as
indication of defunct connections. Even though SHOULD and MAY can be used
together this way, the advise is confusing. This is a case (see below) where
the reasoning behind exceptions to SHOULDs are needed -- but the MAY clause is
a far too trivial (and, based on our experience with BGP, incorrect) condition
- DATA-002 should suggest protocols for security, at least indicating whether
these need to be at a particular protocol layer (IP, transport, application),
etc.

Other issues:
- the document uses SHOULD without qualifying the conditions for exception

Nits
- the abstract is too brief
- Several requirements suggest that use of TCP avoids the need for separate
congestion control; the same should be mentioned of SCTP and DCCP.




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux