RE: [tcpm] New I-D

"Caitlin Bestler" <caitlinb@broadcom.com> Wed, 21 February 2007 20:47 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJyNI-0004Mt-Ai; Wed, 21 Feb 2007 15:47:40 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJyNH-0004LU-KA for tcpm@ietf.org; Wed, 21 Feb 2007 15:47:39 -0500
Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJyNG-0008Ma-8O for tcpm@ietf.org; Wed, 21 Feb 2007 15:47:39 -0500
Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.0)); Wed, 21 Feb 2007 12:47:22 -0800
X-Server-Uuid: 05DA3F36-9AA8-4766-A7E5-53B43A7C42E6
Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 85CE42AF; Wed, 21 Feb 2007 12:47:22 -0800 (PST)
Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 71C682AE; Wed, 21 Feb 2007 12:47:22 -0800 (PST)
Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EYQ11626; Wed, 21 Feb 2007 12:47:21 -0800 (PST)
Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 46A9020502; Wed, 21 Feb 2007 12:47:21 -0800 (PST)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [tcpm] New I-D
Date: Wed, 21 Feb 2007 12:47:20 -0800
Message-ID: <54AD0F12E08D1541B826BE97C98F99F101193892@NT-SJCA-0751.brcm.ad.broadcom.com>
In-Reply-To: <584178.60890.qm@web31707.mail.mud.yahoo.com>
Thread-Topic: [tcpm] New I-D
Thread-Index: AcdV7G9cW6UU9A9cQNKyUApCFbMEeQADEKvA
From: Caitlin Bestler <caitlinb@broadcom.com>
To: MURALI BASHYAM <murali_bashyam@yahoo.com>
X-WSS-ID: 69C2705028C4947306-01-01
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Cc: tcpm@ietf.org, weddy@grc.nasa.gov
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

MURALI BASHYAM wrote:

> 
> I am not sure what the status of the draft is supposed to be,
> would experimental be a more appropriate status?
> Aside from the status of the draft, the more fundamental
> point is whether we agree that this is a protocol specific
> requirement leading to a problem for which there is a
> protocol specific/aware solution we can put in place.
> 

I have always assumed the following:

	Any application MAY disconnect from any peer when
	it no longer finds maintaining the connection with
	the peer to be of value.

	An application SHOULD disconnect from any peer when
	continued support of that peer will have an adverse
	impact on other connections, especially when the
	peer is acting suspiciously.

Therefore any application MAY and perhaps SHOULD disconnect
from a suspiciously idle peer, especially before maintaining
the idle connection adversely impacts active connections.

Are you suggesting that there is anything in any protocol
requirement that contradicts this?


_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm