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

Ted Faber <faber@ISI.EDU> Mon, 26 November 2007 19:56 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 1Iwk3r-0006sv-0F; Mon, 26 Nov 2007 14:56:07 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iwk3p-0006rm-Cg for tcpm-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 14:56:05 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwk3p-0006re-3E for tcpm@ietf.org; Mon, 26 Nov 2007 14:56:05 -0500
Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwk3l-0001iN-2U for tcpm@ietf.org; Mon, 26 Nov 2007 14:56:05 -0500
Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lAQJrpVU004215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Nov 2007 11:53:52 -0800 (PST)
Received: (from faber@localhost) by hut.isi.edu (8.14.2/8.14.2/Submit) id lAQJrpPs045480; Mon, 26 Nov 2007 11:53:51 -0800 (PST) (envelope-from faber)
Date: Mon, 26 Nov 2007 11:53:51 -0800
From: Ted Faber <faber@ISI.EDU>
To: John Heffner <jheffner@psc.edu>
Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]
Message-ID: <20071126195351.GE32459@hut.isi.edu>
References: <20071126142635.8F2E62FBFFD@lawyers.icir.org> <474AEBB4.9010803@isi.edu> <474B2181.7050103@psc.edu>
Mime-Version: 1.0
In-Reply-To: <474B2181.7050103@psc.edu>
User-Agent: Mutt/1.4.2.3i
X-url: http://www.isi.edu/~faber
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: faber@hut.isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: tcpm@ietf.org, mallman@icir.org, Joe Touch <touch@ISI.EDU>
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>
Content-Type: multipart/mixed; boundary="===============0546405033=="
Errors-To: tcpm-bounces@ietf.org

On Mon, Nov 26, 2007 at 02:41:53PM -0500, John Heffner wrote:
> I really have to disagree here; I do not believe an OS terminating a 
> connection violates the spirit of 1122.  Things like processes, address 
> spaces, etc., are well outside the TCP standard's realm.  In my view, an 
> operating system (the kernel, a helper daemon, or other) can be 
> considered a "User" of TCP (in RFC793 terminology), and be fully 
> compliant when making API calls (including ABORT) to connections that 
> might be "owned" by some other process.

I agree with this interpetation, you know, as a regular guy.

> One question: is the deleteTCB(12) state of RFC4022 in conflict with 
> RFC1122/RFC793?

There's nothing there that offends me.  That looks like a request by a
manager to an operating system to call ABORT on a connection.  I assume
that the managed entity might choose to ignore such a request (e.g. it
is a request to terminate the connection to the manager over which the
request came :-)).

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm