Re: Rtgdir last call review of draft-ietf-6man-rfc1981bis-06

[Bob Hinden <[e-mail]>]

Ines,

Thanks for the review.

Comments below.

Bob


> On Apr 22, 2017, at 7:16 AM, Ines Robles <[e-mail]> 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