Reviewer: Magnus Westerlund Review result: Ready with Issues 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 tsv-art@xxxxxxxx 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 relevant. 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.
