Telechat Review of draft-ietf-6man-rfc6434-bis-08
review-ietf-6man-rfc6434-bis-08-tsvart-telechat-westerlund-2018-07-03-00

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@ietf.org 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.