RE: [Tsvwg] SCTP Checksum Change to the IESG

[Scott Bradner <[e-mail]>]

I disagree

if others think that Doug has a point that is important enough to
delay this document even longer please speak up - if there is not
support it is time to move on - if there is support (and more than 
one or two people) then we will delay yet again

Scott

---
From [e-mail]  Thu May  2 04:13:18 2002
From: [e-mail]
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: [Tsvwg] SCTP Checksum Change to the IESG
Date: Thu, 2 May 2002 11:06:13 +0300
Thread-Topic: [Tsvwg] SCTP Checksum Change to the IESG
Thread-Index: AcHxpjxIGhC9zygQSfGHzxp8oSdOagACb13Q
To: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 02 May 2002 08:06:14.0189 (UTC) FILETIME=[3A8C35D0:01C1F1B0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id EAA18023
Sender: [e-mail]
Errors-To: [e-mail]
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Transport Area Working Group <tsvwg.ietf.org>
X-BeenThere: [e-mail]

Hi Scott & Doug,

I think that we need to get this over & done with it.  If this is as
important as Doug thinks it is (so I am willing to say it may be),
then lets just put it to a working group 'vote' - have both 
propsosed texts & have the WG decide which is appropriate.

best regards,
john

> While I agree with this sentiment, the introduction of a hardware
> implementation requirement is new text in conflict with previously raised
> concerns.  It appears Jonathan does not agree there is a need to allow
> implementations where the packet is not modified during the checking
> process.  This is a real problem.  This is true for hardware where an
> unmodified packet allows far greater software compatibility and should be
> the recommended approach.  I was happy with the draft prior to these last
> minute changes that appeared without review.  I was not the one twiddling.
> This is a wrong approach, if to standardize the hardware interface as is the
> intent of this language.
> 
> Presenting an unmodified packet would allow an Alder scheme to be introduced
> in software, as example, without any changes to existing code.  The same is
> equally true for a software CRC algorithm.  The scheme, as defined now, will
> require specialized code to handle such a situation.  The current
> recommendation is clumsy and wrong.  More generalized language would be
> acceptable such as- For hardware checking schemes, software MUST be able to
> confirm the integrity of the packet and not rely exclusively on a status
> bit.  An unmodified packet accomplishes this goal.  This added language has
> compounded an inappropriate algorithm interpretation.


_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg


_______________________________________________
tsvwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg