[RTG-DIR] Rtgdir last call review of draft-ietf-6man-rfc1981bis-06

Ines Robles <mariainesrobles@googlemail.com> Sat, 22 April 2017 04:16 UTC

Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
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)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ines Robles <mariainesrobles@googlemail.com>
To: <rtg-dir@ietf.org>
Cc: ipv6@ietf.org, ietf@ietf.org, draft-ietf-6man-rfc1981bis.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149283456181.25913.15133934620501134310@ietfa.amsl.com>
Date: Fri, 21 Apr 2017 21:16:01 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/eRVeYQR-rQqb8aajO_FkHKonyi0>
Subject: [RTG-DIR] Rtgdir last call review of draft-ietf-6man-rfc1981bis-06
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.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


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.


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[1].

2- Section 1: 

	2.1- I would add a reference when you mention black hole connection.
What about section 2.1 of [2] or [3]?

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 [4] 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

	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 [4] 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

7. Section 6:

	7.1- What about to mention Blind Performance-Degrading Attack [5]?