ipdvb WG Erata List for RFC 4326

This list of corrections is intended for submission to the RFC Editor, on approval of the ipdvb WG. Please inform the WG of any known errors or mistakes, and we will seek to update this page.

7.2. Processing of a Received SNDU

- Usage of last byte in a TS-Packet.

Source: Bernhard Collini-Nocker & Gorry Fairhurst, 15th February 2006
OLD:
“When in the Reassembly State, the Receiver reads a 2-byte SNDU Length field from the TS Packet payload. If the value is less than or equal to 4, or equal to 0xFFFF, the Receiver discards the Current SNDU and”
NEW:
“When in the Reassembly State, the Receiver reads the first two bytes from the TS Packet payload. This value forms the first 2 bytes of the SNDU base header, which is a combination of the D-bit and the SNDU-Length. If the combined value is less than or equal to 4, or equal to 0xFFFF (i.e. D=1 and SNDU Length = 32768), the Receiver MUST discard the Current SNDU and”

Section 4.1

- Length field description refers to a 16-bit value.

Source: Bernhard Collini-Nocker, 15th February 2006
- Proposed change /Length field/first byte of the SNDU base header/
OLD:
"The most significant bit of the Length field carries the value of the Destination Address Absent Field, the D-bit"
NEW:
"The most significant bit of the first byte of the SNDU base header carries the value of the Destination Address Absent Field, the D-bit"

Example A.2

- Misrepresentation of hex byte in example.

Source: Karsten Siebert, 26th February 2006
Proposed change /0x65/0xB5/
OLD:
| HDR | 0x00 | 0x00 | 0xB1 | ... | C180 | 0x00 | 0x65 |
NEW:
| HDR | 0x00 | 0x00 | 0xB1 | ... | C180 | 0x00 | 0xB5 |

Last updated 6th March 2006.