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