RE: [Tsvwg] SCTP Checksum Change to the IESG

the twiddeling with this document has gone on far far too long
at this point I do not see a reason to not have the IESG review this
version unless someone can show that it will not work

someday we have to say that its good enough - and that day is now to me

Scott

---
From tsvwg-admin@ietf.org  Wed May  1 21:39:07 2002
X-Sent: 2 May 2002 01:34:50 GMT
From: "Douglas Otis" <dotis@sanlight.net>
To: <tsvwg@ietf.org>
Subject: RE: [Tsvwg] SCTP Checksum Change to the IESG
Date: Wed, 1 May 2002 18:34:50 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <200205011251.g41CpCX18433@newdev.harvard.edu>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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

Scott,

I see the hardware implementation notes added in
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpcsum-06.txt

A check that 'logically' zeros content of the checksum field during a
checksum calculation and then compares the result to an unaltered field is
robust.  Passing an unaltered packet to a software stack provides a complete
diagnostic should there be a suspected problem with checksum hardware and
allows an unmodified software implementation to take over.  It is clumsy to
alter the packet and then require a means to expose this prior value.  Would
it be possible to suggest presenting an unaltered packet in the event of an
error as an alternative?  Exposing the unaltered CRC is common practice as a
diagnostic.  The CRC field in the header over a hidden zero value is an
unusual case with respect to CRC.  Imposing a read/write/read operation on
this field as opposed to just a read is more prone to error and adds
complexity within the circuit and interface.

 -Doug

On May 1, 2002 5:51 AM Scott Bradner (sob@harvard.edu) wrote:
>
>
> fyi - the revised version of the SCTP checksum chnage will be
> posted today as draft-ietf-tsvwg-sctpcsum-06.txt - this is the
> version that the IESG will consider for publication as a Proposed
> Standard RFC updating RFC 2960.
>
> Scott

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

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