Hi,
> On 08 Mar 2016, at 16:27, Xing Li <[email protected]> wrote:
>
> 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.
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.
>>
>> * 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.
I suggest adding this clarification to the document.
>
>>
>> * 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,
Looks good.
Thanks,
jouni
>
> xing
>
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
