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

Lars Eggert <> Wed, 03 December 2008 09:08 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id E865928C0EB; Wed, 3 Dec 2008 01:08:21 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 481D03A6A9B; Wed, 3 Dec 2008 01:08:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UYQM5lZifl0U; Wed, 3 Dec 2008 01:08:19 -0800 (PST)
Received: from (unknown [IPv6:2001:2060:40:1::123]) by (Postfix) with ESMTP id 733963A68B1; Wed, 3 Dec 2008 01:08:18 -0800 (PST)
Received: from [IPv6:2001:2060:40:2:219:e3ff:fe06:dc74] ([IPv6:2001:2060:40:2:219:e3ff:fe06:dc74]) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id mB397km7091267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Dec 2008 11:07:47 +0200 (EET) (envelope-from
Message-Id: <>
From: Lars Eggert <>
To: Fernando Gont <>
In-Reply-To: <>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Wed, 03 Dec 2008 11:07:45 +0200
References: <> <> <> <>
X-Mailer: Apple Mail (2.929.2)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 ( [IPv6:2001:2060:40:1::123]); Wed, 03 Dec 2008 11:07:47 +0200 (EET)
X-Virus-Scanned: ClamAV 0.94.2/8714/Wed Dec 3 06:37:28 2008 on
X-Virus-Status: Clean
Cc: "" <>, "" <>, "" <>, "" <>, "" <>, "" <>
Subject: Re: [tcpm] Gen-ART review of draft-ietf-tcpm-tcp-soft-errors-08.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: multipart/mixed; boundary="===============0260840854=="

On 2008-12-3, at 10:47, Fernando Gont wrote:
>>> (FYI, the draft originally aimed at Std. Track, and discussed other
>>> alternative  approaches for dealing with the problem of long delays
>>> between connection establishment attempts. Then we changed the draft
>>> category to "Informational", to simply document this behavior. At
>>> that point, the discussion of parallel connections and other
>>> approaches was dropped).
>> I don't think just ignoring this problem is acceptable, but a  
>> reference
>> to a discussion of what can be done about it in that RFC or some  
>> other
>> document should suffice.
> I have produced a separate PDF document with such a discussion, and
> have provided a pointer to it in the Introduction. Please let me know
> if you think this addresses the issue you raised.
> WG: Is this okay with the working group, or is any other approach
> preferred rather than the one I hve taken to adderss David's comments?

Quick follow-up: I have suggested to Fernando the alternative of  
including a short section of text on just this issue in the document  
itself, instead of referencing a PDF that includes a lot of other test  
(the PDF is basically what used to be appendix A, which was removed  
based on WG feedback). But that is also not aligned with prior WG  
consensus, since it would move some text back that we had removed.

Basically, David's comment is asking for some text that WG consensus  
had removed from the document, and we need to come to an agreement on  
whether we want to revisit this consensus and add some text or point  
to another document, or if we want to tell David that he's on the  
rough side of the consensus.

Feedback, please?

tcpm mailing list