Return-Path: X-Original-To: tcpm@core3.amsl.com Delivered-To: tcpm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E423A6863 for ; Thu, 1 Apr 2010 21:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.175 X-Spam-Level: X-Spam-Status: No, score=-0.175 tagged_above=-999 required=5 tests=[AWL=0.960, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk5YppRU5uZy for ; Thu, 1 Apr 2010 21:05:09 -0700 (PDT) Received: from mail.ocarinanetworks.com (mail.ocarinanetworks.com [69.3.29.22]) by core3.amsl.com (Postfix) with ESMTP id 8F8F73A693F for ; Thu, 1 Apr 2010 21:05:07 -0700 (PDT) Received: from exchsvr01.ocarina.local ([10.250.1.7]) by exchsvr01.ocarina.local ([10.250.1.7]) with mapi; Thu, 1 Apr 2010 21:07:31 -0700 From: Murali Bashyam To: "mallman@icir.org" , "Anantha Ramaiah (ananth)" Date: Thu, 1 Apr 2010 21:07:28 -0700 Thread-Topic: [tcpm] poll for adoption of draft-ananth-persist-02 Thread-Index: AcrSDu2qVdEb1uNzTmSxCix/OAy/7QACWS0Q Message-ID: References: <0C53DCFB700D144284A584F54711EC580938B73C@xmb-sjc-21c.amer.cisco.com> <20100402024546.AF102C9C72A@lawyers.icir.org> In-Reply-To: <20100402024546.AF102C9C72A@lawyers.icir.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tcpm@ietf.org" Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02 X-BeenThere: tcpm@ietf.org 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: , X-List-Received-Date: Fri, 02 Apr 2010 04:05:10 -0000 The attempt here via the socket option etc is to describe a guideline to no= rmalize the persist condition connection failure to the excessive retransmi= ssions condition. Note that for the latter connection failure, RFC 1122 say= s TCP SHOULD inform the application unless the app has disabled asynchronou= s reporting of soft errors. Are you suggesting that the guideline is unnece= ssary or out of scope for this document? -----Original Message----- From: mallman@icir.org [mailto:mallman@icir.org]=20 Sent: Thursday, April 01, 2010 7:46 PM To: Anantha Ramaiah (ananth) Cc: Murali Bashyam; tcpm@ietf.org Subject: Re: [tcpm] poll for adoption of draft-ananth-persist-02=20 > > I mean, sure, an app may want to not let a connection hang around=20 > > forever. But, can't it just ABORT whenever it wants? >=20 > Yes, the application can ABORT the connection whenever it wants.=20 >=20 > The socket option is suggested for multiple reasons (use cases) :- Well, that all strikes me as thin. I mean, I don't actually care what sock= et option anyone wants to add, but I agree with John that it doesn't seem l= ike IETF work to me. I certainly wouldn't suggest doing it in a draft that= is meant as a simple clarification of previous RFCs. I am fine with the simple clarification in this draft. I would leave off t= he API gunk. Just my hit. allman