Ines, Thanks for the review. Comments below. Bob > On Apr 22, 2017, at 7:16 AM, Ines Robles <mariainesrobles@xxxxxxxxxxxxxx> wrote: > > 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. > Good, thanks. > > 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]. I will consider it, but sure what it would look like. Suggestions? > > 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]? > I will add RFC2923. The other is an expired draft that I don’t think it appropriate to reference. > 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. > OK > 3.2- I would add also the same references for EMTU_R. OK > > 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. There is a reference to ICMPv6 the first time it shows up in Section 1. I don’t think another is needed for ICMPv6 PTB. > > 4.2- In the first paragraph: "...to send smaller fragments or ..." > --> I think it would be clearer "to send smaller packets or…" I agree, “packets” is better here. It’s consistent with the definition in Section 2. > > 4.3- Second Paragraph: "...process ends when the node's estimate..." > -> "...process ends when the source node's estimate…"? OK > > 4.4- Last Paragraph: "can to appear" -> "can appear" . "...but is in > fact..." -> "...but it is in fact…" OK > > 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) This is described in the previous paragraph. > > > 6.Section 5: > > 6.1- I would add a reference to RFC 1122 [4] when MMS_S is mentioned. OK > > > 6.2- Section 5.5: "Some transport protocols are not allowed to > repacketize when doing a retransmission..." I would add some > examples. I will look into that. > > 7. Section 6: > > 7.1- What about to mention Blind Performance-Degrading Attack [5]? This is protected against by not allow the MTU to be set below 1280 and changes in rfc2460bis fragmentation. > > >> > [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
Attachment:
signature.asc
Description: Message signed with OpenPGP