Proposed change to CRC-processing algorithm from that in ULE Spec -01

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

A new rev. of the ULE Spec will be ready in a few weeks. This will keep the
same protocol, but adding extension processing derived from XULE (see
proceedings of IETF-61). In preparation, the authors have been conducting a
detailed review of the protocol spec.

One other thing that came out in the review was that the following
description seems over specified, and I'd like to propose a minor change
(see below).


X.2 Processing of a Received SNDU

OLD TEXT:
If the Length of the Current SNDU is greater than 4, the Receiver accepts
bytes from the TS Packet payload to the Current SNDU buffer until either
Length bytes in total are received, or the end of the TS Packet is reached.
When Current SNDU length equals the value of the Length Field, the Receiver
MUST calculate and verify the CRC value (section 4.6). SNDUs that contain an
invalid CRC value MUST be discarded, causing the Receiver to re-enter the
Idle State.

PROPOSED NEW TEXT:
If the Length of the Current SNDU is greater than 4, the Receiver accepts
bytes from the TS Packet payload to the Current SNDU buffer until either
Length bytes in total are received, or the end of the TS Packet is reached.
When Current SNDU length equals the value of the Length Field, the Receiver
MUST calculate and verify the CRC value (section 4.6). SNDUs that contain an
invalid CRC value MUST be discarded, and the Receiver processes the next
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
in-sequence SNDU (if any).
^^^^^^^^^^^^^^^^^^^^^^^^^


The rationale is that the this a SNDU-integrity check (CRC) ­ rather than a
framing issue. The IETF emphasis on being "liberal" in what is accepted
suggests we discard the corrupt SNDU, but not that we MUST also discard
succeeding SNDUs. 

Thoughts?

Gorry