RE: [Tsvwg] SCTP Checksum Change to the IESG

["Douglas Otis" <[e-mail]>]

Scott,

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.

 -Doug

On May 1, 2002 6:42 PM Scott Bradner ([e-mail]) wrote:
>
> 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
>
On May 1, 2002 6:34 PM Douglas Otis ([e-mail]) wrote:
>
> 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 ([e-mail]) 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/tsvwg