Subject: Re: [Gen-art] Gen-ART Last Call review of draft-bao-v6ops-rfc6145bis-05

From: Xing Li <[email-masked]>
Date: Wed, 09 Mar 2016 08:27:41 +0800

Hi, Jouni,

Thank you very much for your review and comments. Please see inline.

Jouni Korhonen 写道:
> I am the assigned Gen-ART reviewer for this draft. The General Area 
> Review Team
> (Gen-ART) reviews all IETF documents being processed by the IESG for 
> the IETF
> Chair. Please treat these comments just like any other last call 
> comments. For
> more information, please see the FAQ at
> <​ http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> General:
>
> This draft is ready for publication as a Standards Track RFC, but has 
> few nits I
> would like to get clarification first.
>
> The IDnits throws complains that to me can be fixed by the RFC editor (or
> outdated references automatically when a new revision is generated) 
> and the
> complaints regarding non-compliant RFC3849 & RFC5737 addresses seem to be
> bogus.
>
> Comments:
>
> * Lines 480 and 928 have "advertised MTU", which not really immediately
>   obvious what it means and where it comes from. I would suggest using
>   the exactly same terminology as used in RFC4443 and RFC4884 when
>   referring to values taken from those, for example.

Since this draft is a "bis" of RFC6145, which uses the same wording and the
formula is correct, I would perfer to keep the current terminology.
>
> * Line 367: what is the situation when SHOULD takes place i.e., a packet
>   with "illegal" source address is not silently discarded? Clarify the
>   case.

When translating ICMPv4 Error Messages into ICMPv6, the
"illegal" source address will be translated.
>
> * Line 367: s/siletly drop/silently discard

OK.

>
> * Lines 350, 389-390: payload length is said here to include IPv4 
> options,
>   if present. However, earlier in lines 373-375 it says IPv4 options
>   MUST be ignored so options can never be "if present", right? Suggest
>   aligning the text for consistency if the options are never present in
>   the  translated messages.

The IPv4 options cannot be translated to IPv6, but the length of the
IPv4 options must be counted in order to calculate the correct IPv6 payload
length. We will add notes to clarify this in the next version of the 
document.

>
> * Line 588: what happens to translated IP packet with illegal source
>   addresses? Is this the case for SHOULD referred in line 367?
In this case, the "illegal" source address will be translated for 
trouble shooting.
Yes, this is the case for SHOULD. We will add notes to clarify this in 
the next
version of the document.
> - Jouni
Regards,

xing

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 8 Mar 2016 21:08:56 -0800

Hi,

> On 08 Mar 2016, at 16:27, Xing Li <[email-masked]> wrote:
> 
> Hi, Jouni,
> 
>> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team 
>> (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF 
>> Chair. Please treat these comments just like any other last call comments. For 
>> This draft is ready for publication as a Standards Track RFC, but has few nits I 
>> outdated references automatically when a new revision is generated) and the 

No doubts of the formula. I would still clarify where the “advertised MTU” is taken from. It is not explicitly stated anywhere or referenced to some other document.

> "illegal" source address will be translated.

I suggest adding this clarification to the document.

>> * Lines 350, 389-390: payload length is said here to include IPv4 options, 
> length. We will add notes to clarify this in the next version of the document.
> 
>> 
> In this case, the "illegal" source address will be translated for trouble shooting.
> Yes, this is the case for SHOULD. We will add notes to clarify this in the next 
> version of the document.
>> 
>> - Jouni 
>> 
> Regards,

Looks good.

Thanks,
	jouni

---

From: Xing Li <[email-masked]>
Date: Wed, 09 Mar 2016 16:40:01 +0800

Hi，Jouni,

Thanks. Please see inline.

> No doubts of the formula. I would still clarify where the “advertised MTU” is taken from. It is not explicitly stated anywhere or referenced to some other document.
Got the idea. How about:

474	            Code 4 (Fragmentation Needed and DF was Set):  Translate to
475	               an ICMPv6 Packet Too Big message (Type 2) with Code set
476	               to 0.  The MTU field MUST be adjusted for the difference
477	               between the IPv4 and IPv6 header sizes, but MUST NOT be
478	               set to a value smaller than the minimum IPv6 MTU (1280
479	               bytes).  That is, it should be set to maximum(1280,
480	               minimum((MTU value in the Packet Too Big Message)+20, MTU_of_IPv6_nexthop,
481	               (MTU_of_IPv4_nexthop)+20)).  Note that if the IPv4 router
482	               set the MTU field to zero, i.e., the router does not
483	               implement [RFC1191], then the translator MUST use the
484	               plateau values specified in [RFC1191] to determine a
485	               likely path MTU and include that path MTU in the ICMPv6
486	               packet.  (Use the greatest plateau value that is less
487	               than the returned Total Length field, but that is larger
488	               than or equal to 1280.)

922	      Packet Too Big (Type 2):  Translate to an ICMPv4 Destination
923	         Unreachable (Type 3) with Code 4, and adjust the ICMPv4
924	         checksum both to take the type change into account and to
925	         exclude the ICMPv6 pseudo-header.  The MTU field MUST be
926	         adjusted for the difference between the IPv4 and IPv6 header
927	         sizes, taking into account whether or not the packet in error
928	         includes a Fragment Header, i.e., 
                 minimum((MTU value in the Packet Too Big Message)-20,
929	         MTU_of_IPv4_nexthop, (MTU_of_IPv6_nexthop)-20).

OK.

Best regards,

xing

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 9 Mar 2016 06:40:58 -0800

Hi,

The proposed edits look good to me. Thanks.

- jouni

Sent from a smart phone.. Mind the typos..

On Mar 9, 2016, at 12:40 AM, Xing Li <[email-masked]> wrote:

Hi，Jouni,

Jouni Korhonen 写道:

Comments:

No doubts of the formula. I would still clarify where the “advertised
MTU” is taken from. It is not explicitly stated anywhere or referenced
to some other document.

Got the idea. How about:

480	               minimum((MTU value in the Packet Too Big
Message)+20, MTU_of_IPv6_nexthop,

OK.

Best regards,

xing

---

From: Xing Li <[email-masked]>
Date: Wed, 09 Mar 2016 23:02:17 +0800

> The proposed edits look good to me. Thanks.

Thanks for the confirmation. xing

> On Mar 9, 2016, at 12:40 AM, Xing Li <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Hi，Jouni,
>>

---

From: Congxiao Bao <[email-masked]>
Date: Thu, 10 Mar 2016 11:33:59 +0800

Hi all,

According to the comments during the IETF LC, I have updated and uploaded the -06 version of the draft.

Thank you very much!

Best,

Congxiao

> 在 2016年3月9日，23:02，Xing Li <[email-masked]> 写道：
> 
> Jouni Korhonen 写道:
>> Hi,
>> 
>> On Mar 9, 2016, at 12:40 AM, Xing Li <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> Hi，Jouni,
>>> 
>>>>>> * Lines 480 and 928 have "advertised MTU", which not really immediately   obvious what it means and where it comes from. I would suggest using   the exactly same terminology as used in RFC4443 and RFC4884 when   referring to values taken from those, for example.       
>>>>> Since this draft is a "bis" of RFC6145, which uses the same wording and the formula is correct, I would perfer to keep the current terminology.
>>>>>    
>>> 928	         includes a Fragment Header, i.e.,                  minimum((MTU value in the Packet Too Big Message)-20,
>>>>>> * Line 367: what is the situation when SHOULD takes place i.e., a packet   with "illegal" source address is not silently discarded? Clarify the   case.