Subject: Re: [tcpm] Gen-ART review of draft-ietf-tcpm-tcp-soft-errors-08.txt

From: Lars Eggert <[email-masked]>
Date: Thu, 18 Sep 2008 14:41:24 +0200

Hi,

I believe the gen-art comments need to be discussed before this  
document can move before the IESG.

Lars

On 2008-8-21, at 23:30, ext [email-masked] wrote:

> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-tcpm-tcp-soft-errors-08.txt
> Reviewer: David L. Black
> Review Date: 21 August 2008
> IETF LC End Date: 26 August 2008
>
> Summary:
> This draft is on the right track, but has open issues, described
> in the review.
>
> Comments:
> This is a good draft reporting on problems encountered in practice
> with TCP's handling of ICMP errors and what has been done about
> them.  This draft has received extensive discussion in the Transport
> Area, and I believe it is wise to defer to the Transport Area decision
> that this draft will not make any changes to the TCP standard.
>
> While the draft is in generally good shape, I did find three open
> issues:
>
> (1) The I-D Tracker says that the v6ops-v6onbydefault draft is Dead.
> Relevant portions of that draft should be reproduced or otherwise
> explained in Section 3.2.  As part of doing this, please state
> whether trying v6 and v4 connections in parallel is a good idea or
> not and why.
>
> (2) Section 4.1 describes a mechanism from RFC 3168 that retransmits a
> modified SYN when an RST is received in response to an ECN-setup SYN,
> and suggests that this mechanism is applicable to ICMP errors received
> in response to an ECN-setup SYN.  This mechanism was specified in
> RFC 3168 because there were known deployed middleboxes with this
> problem-causing RST behavior, and the mechanism was necessary to deal
> with them.  Are there any known middleboxes that send an ICMP error
> in response to a SYN that signals ECN capability?
> - If yes, state the specific ICMP error(s) that is(are) used and limit
> 	the recommendation to the actual error(s).
> - If no, remove this entire RFC 3168 discussion as speculative, or
> 	describe it as a possible response should this problem scenario
> 	ever arise in practice.
>
> (3) Section 5.3 describes a NAT behavior that causes a host TCP  
> problem
> and then suggests changing the NAT to fix it.  While that's a good  
> idea
> in an ideal world (and needs to be stated in the draft), in practice,
> deployed NATs have to be dealt with as-is.  In addition to  
> recommending
> fixing the NAT, please discuss what could be done when the NAT cannot
> be fixed.
>
> Nits:
>
> Section 1 - reduce generality of this text.
> OLD:
>   This document analyzes the fault recovery strategy of TCP [RFC0793],
>   and the problems that may arise due to TCP's reaction to ICMP soft
>   errors.
> NEW:
>   This document analyzes problems that may arise due to TCP [RFC0793]
>   fault recovery reactions to ICMP soft errors.
>
> It would be good to provide the text expansion of the codes in
> Figure 1, as was done in the text before the figure.
>
> In section 4, please provide the expansion of TCPM WG (TCP Maintenance
> Working Group).
>
> idnits 2.08.10 ran clean.
>
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------

_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm