Telechat Review of draft-ietf-6man-rfc6434-bis-08

Request Review of draft-ietf-6man-rfc6434-bis
Requested rev. no specific revision (document currently at 09)
Type Telechat Review
Team Transport Area Review Team (tsvart)
Deadline 2018-07-03
Requested 2018-06-25
Authors Tim Chown, John Loughney, Timothy Winters
Draft last updated 2018-07-03
Completed reviews Opsdir Last Call review of -08 by Scott Bradner (diff)
Rtgdir Last Call review of -08 by Russ White (diff)
Genart Last Call review of -09 by Vijay Gurbani
Secdir Last Call review of -09 by Tobias Gondrom
Tsvart Telechat review of -08 by Magnus Westerlund (diff)
Assignment Reviewer Magnus Westerlund 
State Completed
Review review-ietf-6man-rfc6434-bis-08-tsvart-telechat-westerlund-2018-07-03
Reviewed rev. 08 (document currently at 09)
Review result Ready with Issues
Review completed: 2018-07-03


I've reviewed this document as part of the transport area directorate'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 for
their information and to allow them to address any issues raised.
When done at the time of IETF Last Call, the authors should consider this
review together with any other last-call comments they receive.
Please always CC if you reply to or forward this review.

I have focused on the transport aspects of these node requirements and have two things I would like to flag that should be considered to be addressed. 

A. Section 5.7.1:

Path MTU Discovery relies on ICMPv6 Packet Too
   Big (PTB) to determine the MTU of the path (and thus these should not
   be filtered, as per the recommendation in [RFC4890]).

Considering that RFC 4890 recommendation for PTB is "Traffic That Must Not Be Dropped". I think using "should not" is weaking the recommendation. 

B. Section 5.12:

   Nodes that may be deployed in environments where they would benefit
   from such early congestion notification SHOULD implement [RFC3168].
   In such cases, the updates presented in [RFC8311] may also be

Why isn't this a MUST? A IPv6 node has no way of determining if it is has connectivity that will actively mark with ECN-CE. However, a very large part of the current Internet is actually ECN Capable Transport (ECT) (>90%). Also we are talking about supporting handling of two bits that are part of the fixed IPv6 header. Not requiring that the IPv6 host itself is ECT could result in a reduction of the capability of the network. A node will at least be required to set the bits as not being ECT if there are no transport protocol function requesting setting the ECN bits to ECT.