IETF Logo Mail Archive

RE: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]

"Anantha Ramaiah (ananth)" <ananth@cisco.com> Mon, 26 November 2007 06:04 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwX5S-0000A1-R9; Mon, 26 Nov 2007 01:04:54 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1IwX5S-00009w-CI for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 01:04:54 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwX5S-00009o-1X for tcpm@ietf.org; Mon, 26 Nov 2007 01:04:54 -0500
Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwX5R-0006P7-M8 for tcpm@ietf.org; Mon, 26 Nov 2007 01:04:53 -0500
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 25 Nov 2007 22:04:53 -0800
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAQ64qgJ021643; Sun, 25 Nov 2007 22:04:52 -0800
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAQ64qb4016254; Mon, 26 Nov 2007 06:04:52 GMT
Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 25 Nov 2007 22:04:52 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]
Date: Sun, 25 Nov 2007 22:04:51 -0800
Message-ID: <0C53DCFB700D144284A584F54711EC580452BCE0@xmb-sjc-21c.amer.cisco.com>
In-Reply-To: <474A5299.8040301@isi.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]
Thread-Index: Acgv6TQcvWwnfUnEQqu2N2Rq4YL9FgABbqWw
From: "Anantha Ramaiah (ananth)" <ananth@cisco.com>
To: Joe Touch <touch@ISI.EDU>
X-OriginalArrivalTime: 26 Nov 2007 06:04:52.0165 (UTC) FILETIME=[42570750:01C82FF2]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1009; t=1196057092; x=1196921092; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ananth@cisco.com; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<ananth@cisco.com> |Subject:=20RE=3A=20Summary=20of=20responses=20so=20far=20and=20proposal= 20moving=09forward[WasRe=3A=20[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=aZyLEuJXZQaaTHcdUPb3SUHgzpY55CpCxUHbAZpvRPs=; b=gO8FI9sdq6y52so8rjJS8rGXhUviaRdzHdHf2UP68iItr9s17Wn+Yb4ScDJG54QPC9zsao9x D/aBbTnMZSt8TLzM0uH0cU8/M4/r9XLTd8+ashblxEIaOOMZOqQYRJ0N;
Authentication-Results: sj-dkim-4; header.From=ananth@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: tcpm@ietf.org, Tom Petch <nwnetworks@dial.pipex.com>
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

 
> > 
> > IMO, the informational RFC which is what is being attempted, should 
> > clarify this. The whole point of my question was to 
> understand whether 
> > terminating a connection stuck in persist state is 
> considered RFC 1122 
> > compliant. It appears from responses so far, it is compliant.
> 
> 1122 allows terminating a connection at any time for the 
> reason that the application has instructed so. 1122 makes no 
> distinction about the progress of a connection affecting that control.

Implicit above OR an example scenario of the above statement is :, "1122
allows terminating connection stuck in persist state". Now how and where
it is done is beyond the scope of any standard RFC (including 1122) and
there are several ways to implement the rules.

Now "progress of a connection and taking some action" all fall under
implementation section, aborting of the connection is like a knob, you
turn it when you determine that you need it.

-Anantha


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

v2.23.0 | Report a Bug | By Email