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 Black_David@xxxxxxx 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 > black_david@xxxxxxx Mobile: +1 (978) 394-7754 > ---------------------------------------------------- _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf