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

[Magnus Westerlund <[e-mail]>]

Hi,

Thanks for the rapid response.


Den 2018-07-03 kl. 22:48, skrev Brian E Carpenter:
> 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.

So, I don't consider it a major weakening, but non the less "must not" 
is stricter than "should not".

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

I wished I had reviewed this earlier (during the WG process) because I 
think ECN is so stable and mature with a small implementation burden 
from the IP layer that it really should be mandated to implement. At the 
same time I do realize that a stack that simply ignores the bits and 
sets them to 00 on outgoing IPv6 packets are fully interoperable so that 
this is not an argument for mandating implementation. But, I really 
wanted to flag this for the ADs. From my perspective the SHOULD is the 
minimal level ECN should be required to be implemented at, and I had 
hoped for a MUST. And I think the only one that has a reason not to 
implement ECN in the IP layer are low performance minimal footprint 
implementation.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------