[RTG-DIR] Rtgdir last call review of draft-ietf-6man-rfc1981bis-06
Ines Robles <firstname.lastname@example.org> Sat, 22 April 2017 04:16 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C8812944A; Fri, 21 Apr 2017 21:16:01 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Ines Robles <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Date: Fri, 21 Apr 2017 21:16:01 -0700
Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-6man-rfc1981bis-06
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Apr 2017 04:16:02 -0000
Reviewer: Ines Robles Review result: Has Nits Document: draft-ietf-6man-rfc1981bis-06.txt Reviewer: Ines Robles Review Date: April 21, 2017 Intended status: Standards Track Summary: This document describes Path MTU Discovery for IP version 6 I believe the draft is technically good. I have no “Major” issues with this I-D. I have some minor comments. Comments: 1- I think that it would be nice to add a graphical example that describes the process of the Path MTU Discovery (including a Packet Too Big Message). e.g. Figure 1 of RFC 5927. 2- Section 1: 2.1- I would add a reference when you mention black hole connection. What about section 2.1 of  or ? 3- Section 2: 3.1- EMTU_S => When it is defined, it references RFC6691. But this term is not mentioned in RFC6691. I would add additionally a reference to RFC 1122  which defines EMTU_S. 3.2- I would add also the same references for EMTU_R. 4.Section 3: 4.1- In the first paragraph, I would add a reference to ICMPv6 the first time that ICMPv6 Packet Too Big message is mentioned. And I would add here also "(ICMPv6 PTB)" since it used further in the document. 4.2- In the first paragraph: "...to send smaller fragments or ..." --> I think it would be clearer "to send smaller packets or..." 4.3- Second Paragraph: "...process ends when the node's estimate..." -> "...process ends when the source node's estimate..."? 4.4- Last Paragraph: "can to appear" -> "can appear" . "...but is in fact..." -> "...but it is in fact..." 5. Section 4: 4.1- about this: "The node MUST reduce the size of the packets it is sending along the path". I would add an explanation to which size the packet should be reduced (maybe based in an initial example) 6.Section 5: 6.1- I would add a reference to RFC 1122  when MMS_S is mentioned. 6.2- Section 5.5: "Some transport protocols are not allowed to repacketize when doing a retransmission..." I would add some examples. 7. Section 6: 7.1- What about to mention Blind Performance-Degrading Attack ?