[RTG-DIR] Review for draft-ietf-6man-rfc1981bis-06

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

MIME-Version: 1.0
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Sat, 22 Apr 2017 01:14:05 -0300
Message-ID: <CAP+sJUcvrYC=RkZh=VN+BNpCxK3j=jBS9-3Xb=Q1kb3rcjGzEQ@mail.gmail.com>
To: draft-ietf-6man-rfc1981bis@ietf.org
Cc: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, rtg-ads@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0940d2da1ea4054db99a96"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/IHoJt7vQGOvXh_GNQJ_c4mVmUng>
Subject: [RTG-DIR] Review for draft-ietf-6man-rfc1981bis-06
Precedence: list

Hi,


Please find my review for "Path MTU Discovery for IP version 6
(draft-ietf-6man-rfc1981bis-06) I-D:

................................................................................................................................

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

7. Section 6:

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

--------------------------------------------------------------------------------------------------------------

Thank you,

Ines.



[1] https://tools.ietf.org/html/rfc5927#section-7.3
[2] https://tools.ietf.org/html/rfc2923
[3]
https://tools.ietf.org/html/draft-jacquin-opsawg-icmp-blackhole-problem-00
[4] https://tools.ietf.org/html/rfc1122#page-58
[5] https://tools.ietf.org/html/rfc5927#section-7

[RTG-DIR] Review for draft-ietf-6man-rfc1981bis-06 Ines Robles