Re: [Tsv-art] Tsvart telechat review of draft-ietf-6man-rfc6434-bis-08

[Brian E Carpenter <[e-mail]>]

Hi Magnus,
On 04/07/2018 02:45, Magnus Westerlund wrote:
> 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 [e-mail] 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.

Interesting point. This is a lower case "should" so actually I don't think
it is really a weakening, but by the same argument "must not" is OK too.

> 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.

I think the problem in that sentence is the "may be deployed..." clause.
The implementer of a stack can't possibly know that. So why not reduce it
to:
   Nodes SHOULD implement [RFC3168].
In RFC2119 terms that's fine, since it simply says "do this unless you
have a good reason not to."

   Brian

> 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.
> 
>