Re: [Tsvwg] SCTP Checksum Change to the IESG

Randall Stewart <randall@stewart.chicago.il.us> Thu, 02 May 2002 22:47 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17006 for <tsvwg-archive@odin.ietf.org>; Thu, 2 May 2002 18:47:41 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA14482 for tsvwg-archive@odin.ietf.org; Thu, 2 May 2002 18:47:45 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13083; Thu, 2 May 2002 18:25:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA13056 for <tsvwg@ns.ietf.org>; Thu, 2 May 2002 18:25:10 -0400 (EDT)
Received: from stewart.chicago.il.us (user166.64.47.24.dsli.com [64.47.24.166]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16481 for <tsvwg@ietf.org>; Thu, 2 May 2002 18:25:05 -0400 (EDT)
Received: from stewart.chicago.il.us (stewlap [10.1.1.5]) by stewart.chicago.il.us (8.11.1/8.11.1) with ESMTP id g42M6NH68344; Thu, 2 May 2002 17:06:23 -0500 (CDT) (envelope-from randall@stewart.chicago.il.us)
Message-ID: <3CD1B85E.5FB6933F@stewart.chicago.il.us>
Date: Thu, 02 May 2002 17:06:22 -0500
From: Randall Stewart <randall@stewart.chicago.il.us>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Scott Bradner <sob@harvard.edu>
CC: tsvwg@ietf.org
Subject: Re: [Tsvwg] SCTP Checksum Change to the IESG
References: <200205011251.g41CpCX18433@newdev.harvard.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: tsvwg-admin@ietf.org
Errors-To: tsvwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Transport Area Working Group <tsvwg.ietf.org>
X-BeenThere: tsvwg@ietf.org
Content-Transfer-Encoding: 7bit

Scott/All:

Has I surmised Jonathan is not on the tsvwg list. I have
however spoken to him on the phone and just sent him
this entire thread (up to Pat Thalers last post). 

He is going to digest it and post some responses
to this chain of debate :-)

Now my brief and somewhat limited understanding of his
position is that the Go-Nogo hardware bit is unacceptable
not for when it tells you No-go.. but for when it tells
you GO.

The idea being if it is broken DMA and pulls a bad value
from the packet for the checksum.. checks the packet and
it matches .. it tells you GO.. 

You have no clue in software to re-audit and check it. 

If it returns to you GO and here was the value I used
from the packet to compute it... 

You can, upon seeing the GO compare the value it used
with the packets checksum and if correct.. good.. if bad
you then do the software checksum..

Jonathan will post other details with his reasoning here as
well.. but lets give him some time to digest the 29 or so emails
in this thread :>

Regards

R

-- 
Randall R. Stewart
randall@stewart.chicago.il.us 815-342-5222 (cell phone)

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