Last Call Review of draft-ietf-6man-rfc1981bis-06
review-ietf-6man-rfc1981bis-06-rtgdir-lc-robles-2017-04-21-01

Request Review of draft-ietf-6man-rfc1981bis
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Routing Area Directorate (rtgdir)
Deadline 2017-03-01
Requested 2017-02-10
Requested by Alvaro Retana
Draft last updated 2017-05-05
Completed reviews Intdir Early review of -03 by Donald Eastlake (diff)
Secdir Last Call review of -04 by Rifaat Shekh-Yusef (diff)
Genart Last Call review of -04 by Stewart Bryant (diff)
Opsdir Last Call review of -04 by Susan Hares (diff)
Tsvart Telechat review of -04 by Joseph Touch (diff)
Rtgdir Last Call review of -06 by Ines Robles (diff)
Secdir Telechat review of -06 by Rifaat Shekh-Yusef (diff)
Genart Telechat review of -06 by Stewart Bryant (diff)
Assignment Reviewer Ines Robles
State Completed
Review review-ietf-6man-rfc1981bis-06-rtgdir-lc-robles-2017-04-21
Reviewed rev. 06 (document currently at 08)
Review result Has Nits
Review completed: 2017-05-05

Review
review-ietf-6man-rfc1981bis-06-rtgdir-lc-robles-2017-04-21

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:

 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 the same references for EMTU_R as well.
 
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, about this: "...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]
 

Thanks,

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