Last Call Review of draft-ietf-dots-requirements-16
review-ietf-dots-requirements-16-tsvart-lc-touch-2018-11-17-00

Request Review of draft-ietf-dots-requirements
Requested rev. no specific revision (document currently at 22)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2018-11-09
Requested 2018-10-26
Authors Andrew Mortensen, Tirumaleswar Reddy.K, Robert Moskowitz
Draft last updated 2018-11-17
Completed reviews Secdir Last Call review of -16 by Brian Weis (diff)
Opsdir Last Call review of -16 by Scott Bradner (diff)
Tsvart Last Call review of -16 by Joseph Touch (diff)
Genart Last Call review of -16 by Robert Sparks (diff)
Genart Telechat review of -18 by Robert Sparks (diff)
Assignment Reviewer Joseph Touch
State Completed
Review review-ietf-dots-requirements-16-tsvart-lc-touch-2018-11-17
Reviewed rev. 16 (document currently at 22)
Review result Ready with Issues
Review completed: 2018-11-17

Review
review-ietf-dots-requirements-16-tsvart-lc-touch-2018-11-17

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.