RFC Errata
Found 4 records.
Status: Verified (1)
RFC 5651, "Layered Coding Transport (LCT) Building Block", October 2009
Source of RFC: rmt (tsv)
Errata ID: 3843
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eric Turcotte
Date Reported: 2013-12-16
Verifier Name: Martin Stiemerling
Date Verified: 2015-12-16
Section 5.2.1 says:
There are two formats for Header Extension fields, as depicted in Figure 2. The first format is used for variable-length extensions, with Header Extension Type (HET) values between 0 and 127. The second format is used for fixed-length (one 32-bit word) extensions, using HET values from 127 to 255.
It should say:
There are two formats for Header Extension fields, as depicted in Figure 2. The first format is used for variable-length extensions, with Header Extension Type (HET) values between 0 and 127. The second format is used for fixed-length (one 32-bit word) extensions, using HET values from 128 to 255.
Notes:
the correct range for one 32-bit word extension HET values starts from 128, and not from 127.
Status: Reported (1)
RFC 5651, "Layered Coding Transport (LCT) Building Block", October 2009
Source of RFC: rmt (tsv)
Errata ID: 7638
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Sam Hurst
Date Reported: 2023-09-11
Section 2 says:
Beyond support for congestion control, LCT provides a number of fields and supports functionality commonly required by many protocols. For example, LCT provides a Transmission Session ID that can be used to identify to which session each received packet belongs. This is important because a receiver may be joined to many sessions concurrently, and thus it is very useful to be able to demultiplex packets as they arrive according to the session to which they belong. As another example, there are optional fields within the LCT packet header for identifying the object about which information is carried in the packet payload.
It should say:
Beyond support for congestion control, LCT provides a number of fields and supports functionality commonly required by many protocols. For example, LCT provides a Transport Session ID that can be used to identify to which session each received packet belongs. This is important because a receiver may be joined to many sessions concurrently, and thus it is very useful to be able to demultiplex packets as they arrive according to the session to which they belong. As another example, there are optional fields within the LCT packet header for identifying the object about which information is carried in the packet payload.
Notes:
There is an inconsistency in the definition of the TSI acronym. There are 6 instances of TransPORT session identifier/ID, and 2 instances of TransMISSION session identifier/ID. The other instance is in section 3, paragraph 3 ("One of the required fields is the TransMISSION Session ID (TSI).")
Status: Held for Document Update (2)
RFC 5651, "Layered Coding Transport (LCT) Building Block", October 2009
Source of RFC: rmt (tsv)
Errata ID: 2000
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-10
Held for Document Update by: Magnus Westerlund
Section 6.1, pg. 25 says:
[ second-to-last paragraph, mid-page 25 : ] For the reasons mentioned above, this document does not pose any restriction on packet sizes. However, network efficiency considerations recommend that the sender uses an as large as possible packet payload size, but in such a way that packets do not exceed the | network's maximum transmission unit size (MTU), or when fragmentation coupled with packet loss might introduce severe inefficiency in the transmission.
It should say:
For the reasons mentioned above, this document does not pose any restriction on packet sizes. However, network efficiency considerations recommend that the sender uses an as large as possible packet payload size, but in such a way that packets do not exceed the | network's maximum transmission unit size (MTU), because fragmentation coupled with packet loss might introduce severe inefficiency in the transmission.
Notes:
Rationale: "or when" does not make proper sense here; "because" does.
Errata ID: 2001
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2010-01-10
Held for Document Update by: Magnus Westerlund
Section 5.2.1, pg.20 says:
EXT_AUTH, HET=1 Packet authentication extension. Information used to
authenticate the sender of the packet. The format of
this Header Extension and its processing is outside
the scope of this document and is to be communicated
out-of-band as part of the session description.
| It is RECOMMENDED that senders provide some form of packet
authentication. If EXT_AUTH is present, whatever
packet authentication checks that can be performed
immediately upon reception of the packet SHOULD be
performed before accepting the packet and performing
any congestion-control-related action on it.
| Some packet authentication schemes impose a delay of several seconds
between when a packet is received and when the packet
is fully authenticated. Any congestion control
related action that is appropriate SHOULD NOT be
postponed by any such full packet authentication.
It should say:
EXT_AUTH, HET=1 Packet authentication extension. Information used to
authenticate the sender of the packet. The format of
this Header Extension and its processing is outside
the scope of this document and is to be communicated
out-of-band as part of the session description.
| It is RECOMMENDED that senders provide some form of
packet authentication. If EXT_AUTH is present,
whatever packet authentication checks that can be
performed immediately upon reception of the packet
SHOULD be performed before accepting the packet and
performing any congestion-control-related action on
it.
| Some packet authentication schemes impose a delay of
several seconds between when a packet is received and
when the packet is fully authenticated. Any
congestion control related action that is appropriate
SHOULD NOT be postponed by any such full packet
authentication.
Notes:
Rationale:
Improper formatting of hanging list item consisting of three
paragraphs, visually pretending two more list items;
flaw apparently introduced in final pre-publication stages --
drafts were formatted properly.