RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 14 records.

Status: Verified (5)

RFC 4996, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", July 2007

Note: This RFC has been obsoleted by RFC 6846

Source of RFC: rohc (tsv)

Errata ID: 1291

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Verifier Name: Magnus Westerlund
Date Verified: 2009-09-07

Section 6.3.3 (end) says:

      Item 1, ..., item n: Each item corresponds to an XI with X = 1 in
      XI 1, ..., XI m.  The format of the entries in the item list is
|     described in Section 6.2.
                           ^^^^

It should say:


      Item 1, ..., item n: Each item corresponds to an XI with X = 1 in
      XI 1, ..., XI m.  The format of the entries in the item list is
|     encoded by the encoding method found in the table of Section 6.3.
|     The compressed format(s) suffixed by "_list_item" in the encoding
|     methods defines the item inside the compressed item list.
 

Notes:

6.2 definitely does not contain this information.
I did not find a section that actually gives all these
details, as could be expected.

Maybe, something has been lost during the development of the document.

Authors and WG chair provided the corrected text with additional details.

Errata ID: 1292

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Verifier Name: Magnus Westerlund
Date Verified: 2009-09-07

Section 6.4.3 (end) says:

   The "inferred_ip_v4_length" encoding method compresses the IPv4
|  header checksum down to a size of zero bits.  Using this encoding
   method, the decompressor infers the value of this field by counting
   in octets the length of the entire packet after decompression.

It should say:

   The "inferred_ip_v4_length" encoding method compresses the IPv4
|  Total Length field down to a size of zero bits.  Using this encoding
   method, the decompressor infers the value of this field by counting
   in octets the length of the entire packet after decompression.

Notes:

Apparently missed edit after copy & paste.

Errata ID: 1293

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Verifier Name: Magnus Westerlund
Date Verified: 2009-09-07

Section 6.4.8.2,p.34 says:

   Establishing residue:

|     The scaling factor is established by sending unscaled TCP
                  ^^^^^^
      Acknowledgment Number bits, so that the decompressor can infer its
      value from the unscaled value and the scaling factor (ack_stride).

It should say:

   Establishing residue:

|     The scaling residue is established by sending unscaled TCP
                  ^^^^^^^^
      Acknowledgment Number bits, so that the decompressor can infer its
      value from the unscaled value and the scaling factor (ack_stride).

Notes:

Apparently missed edit after copy & paste from preceding paragraph.

Errata ID: 1298

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Verifier Name: Magnus Westerlund
Date Verified: 2009-09-07

Section 8.2, p.67 says:

   COMPRESSED sack2_list_item {
     discriminator =:= '00000010';
     block_1       =:= sack_block(ack_value);
     block_2       =:= sack_block(block_1_end.UVALUE);
     ENFORCE(length.UVALUE == 18);
   }

It should say:

   COMPRESSED sack2_list_item {
     discriminator =:= '00000010';
     block_1       =:= sack_block(ack_value);
|    block_2       =:= sack_block(block_1.UVALUE && 0xFFFFFFFF);
     ENFORCE(length.UVALUE == 18);
   }

Notes:

ROHC-FN is intended to introduce precision.
Therefore, no ad-hoc variable names should be introduced,
independent of how mnemonic their names might be.

I hope that the NEW text substituted above indeed is what had been
intended.

Similar corrections need to be applied on page 68 (10 instances)
and on top of page 69 (one instance).

Errata ID: 1299

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Verifier Name: Magnus Westerlund
Date Verified: 2009-09-07

Section 8.2, p.69 says:

 tcp_opt_generic
 {
   UNCOMPRESSED {
     type                                    [ 8 ];
     length_msb =:= uncompressed_value(1, 0) [ 1 ];
     length_lsb                              [ 7 ];
|    contents                           [ length_len.UVALUE*8-16 ];
   }
                                                 ^^^

It should say:

 tcp_opt_generic
 {
   UNCOMPRESSED {
     type                                    [ 8 ];
     length_msb =:= uncompressed_value(1, 0) [ 1 ];
     length_lsb                              [ 7 ];
|    contents                           [ length_lsb.UVALUE*8-16 ];
   }
                                                 ^^^

Notes:

'length_len' has never been introduced.
This must be a confusing typo, invalidating the formal specification.

Tis same correction needs to be applied once more, near the bottom
of page 69.

Status: Held for Document Update (3)

RFC 4996, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", July 2007

Note: This RFC has been obsoleted by RFC 6846

Source of RFC: rohc (tsv)

Errata ID: 1290

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Held for Document Update by: Magnus Westerlund

Section 5.2.1.1 says:

   The optimistic approach is the principle by which a compressor sends
   the same type of information for a number of packets (consecutively
   or not) until it is fairly confident that the decompressor has
   received the information.  The optimistic approach is useful to
|  ensure robustness when ROHC-TCP is used to compress packet over lossy
   links.

It should say:

   The optimistic approach is the principle by which a compressor sends
   the same type of information for a number of packets (consecutively
   or not) until it is fairly confident that the decompressor has
   received the information.  The optimistic approach is useful to
|  ensure robustness when ROHC-TCP is used to compress packets over
   lossy links.
                                                             ^

Errata ID: 1296

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Held for Document Update by: Magnus Westerlund

Section 7.1, p.37 says:

      Payload: The payload of the corresponding original packet, if any.
      The payload consists of all data after the last octet of the TCP
|     header to end of the uncompressed packet.  The presence of a
      payload is inferred from the packet length.

It should say:

      Payload: The payload of the corresponding original packet, if any.
      The payload consists of all data after the last octet of the TCP
|     header to the end of the uncompressed packet.  The presence of a
      payload is inferred from the packet length.

Notes:

Location is last paragraph in unnumbered subsection on IR packet type.

Errata ID: 1297

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Held for Document Update by: Magnus Westerlund
Date Held: 2009-09-07

Section 7.2, p.39 says:

|  The ROHC-TCP IR-CR packet follows the general format of the ROHC CR
   packet, as defined in [RFC4164], Section 3.5.2.  [...]
   

It should say:

   The ROHC-TCP IR-CR packet follows the general format of the ROHC
|  IR-CR packet, as defined in [RFC4164], Section 3.5.2.  [...]
 

Notes:

RFC 4996 should use precise terminology established in RFC 4995
and RFC 4164.
"CR" does not appear anywhere in both RFCs (and it does not recur in
RFC 4996 as well); "IR-CR" should be used for clarity and precision.

Chair reply: It should be IR-CR and there is no CR defined in the document, but I think most people will understand the sentence. Still, if/when we update this document we should make this correction. So hold for update.

Status: Rejected (6)

RFC 4996, "RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)", July 2007

Note: This RFC has been obsoleted by RFC 6846

Source of RFC: rohc (tsv)

Errata ID: 1288

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Rejected by: Magnus Westerlund
Date Rejected: 2009-09-07

Throughout the document, when it says:

IR

It should say:

IR and IR-DYN

Notes:

RFC 4996 is very confusing regarding the ROHC packet types used.
Section 2 (on top of page 5) says only 3 types are used: IR, IR-CR, and CO.
This is restated in a few places.
But significant text in RFC 4996 also details the use of the IR-DYN
packet type.

According to RFC 4995, IR-DYN is a distinct packet type.

It looks like the terminology has been floating for some time,
and the text of RFC 4996 has not been adjusted to the final
terminology used in RFC 4995, before publication as an RFC,
although both RFCs have been published in a coordinated way.

To give the reader a hint on the problem, I suggest a change note
for Section 2 -- this will be posted as a separate Errata Note --
and detail the other places in the text affected by this issue
in an accompanying message to be evalueated by the verifiers,
to avoid an email avalanche.
This report will also include other issues found not suitable for
reporting via this form based system.
--VERIFIER NOTES--
Authors and WG chairs are of the opinion that it is reasonably clear that IR is both a class of packets type. So from the context it should be understandable when the class is meant rather than the specific type. And clarification would also require major changes in several docs.

Errata ID: 1289

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Rejected by: Magnus Westerlund
Date Rejected: 2009-09-07

Section 2, pg. 5 says:

   ROHC-TCP packet types

      ROHC-TCP uses three different packet types: the Initialization and
      Refresh (IR) packet type, the Context Replication (IR-CR) packet
      type, and the Compressed packet (CO) type.


It should say:

   ROHC-TCP packet types

      ROHC-TCP uses four different packet types: the Initialization and
      Refresh (IR) packet type, the IR-DYN (IR, dynamic update) packet
      type, the Context Replication (IR-CR) packet type, and the
      Compressed packet (CO) type.


Notes:

ROHC-TCP makes use of IR-DYN packets, as can be seen in other parts
of the text.
According to RFC 4995, IR-DYN is a distinct ROHC packet type,
and RFC 4995 does not contain the notion of a packet sub-type
that might have justified subsuming IR-DYN as a non-self-sustaining
packet always to be included/assumed as well when talking about the
IR packet type.

For more information see the GLOBAL Errata Report issued on this topic.
--VERIFIER NOTES--
Authors and WG chairs are of the opinion that it is reasonably clear that IR is both a class of packets type. So from the context it should be understandable when the class is meant rather than the specific type. And clarification would also require major changes in several docs.

Errata ID: 1294

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Rejected by: Magnus Westerlund
Date Rejected: 2009-09-07

Section 7, 1st para says:

   ROHC-TCP uses three different packet types: the Initialization and
   Refresh (IR) packet type, the Context Replication (IR-CR) packet
   type, and the Compressed (CO) packet type.

It should say:

   ROHC-TCP uses four different packet types: the Initialization and
   Refresh (IR) packet type, the Initialization and Refresh - Dynamic
   Part (IR-DYN) packet type, the Context Replication (IR-CR) packet
   type, and the Compressed (CO) packet type.

Notes:

See GLOBAL errata report on IR <-> IR-DYN for rationale.
--VERIFIER NOTES--
Authors and WG chairs are of the opinion that it is reasonably clear that IR is both a class of packets type. So from the context it should be understandable when the class is meant rather than the specific type. And clarification would also require major changes in several docs.

Errata ID: 1295

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Rejected by: Magnus Westerlund
Date Rejected: 2009-09-07

Section 7.1 says:

7.1.  Initialization and Refresh (IR) Packets

It should say:

7.1.  Initialization and Refresh (IR and IR-DYN) Packets

Notes:

See GLOBAL errata report on IR <-> IR-DYN for rationale.
--VERIFIER NOTES--
Authors and WG chairs are of the opinion that it is reasonably clear that IR is both a class of packets type. So from the context it should be understandable when the class is meant rather than the specific type. And clarification would also require major changes in several docs.

Errata ID: 1300

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2008-01-21
Rejected by: Magnus Westerlund
Date Rejected: 2009-09-07

Section 8.3.2.3 says:

|  These 2 bits are the least significant bits of the MSN and are thus
   concatenated with the 14 bits already present in the FEEDBACK-2
   format.

It should say:

|  These 2 bits are the most significant bits of the MSN and are thus
   concatenated with the 14 bits already present in the FEEDBACK-2
   format.

Notes:

It does not make much sense to "provide 2 additional bits"
for a numerical value, and taking the *least* significant bits
for this purpose. This way, the interpretation of the other
encoded MSN bits would prematurely be changed by the presence
of the MSN option.
Therefore, I strongly suspect that the text is in error and
should be corrected as above.
--VERIFIER NOTES--
WG chair Calle Knutsson: This is the way we handle lsbs.

Errata ID: 3637

Status: Rejected
Type: Editorial

Reported By: Raj Kumar
Date Reported: 2013-06-04
Rejected by: Martin Stiemerling
Date Rejected: 2015-12-16

Section 8.2 says:

COMPRESSED rout_opt_0_replicate {
    discriminator =:= '10000000'                     [ 8 ];
    length        =:= irregular(8)                   [ 8 ];
    value         =:=
      irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
  }

It should say:

COMPRESSED rout_opt_1_replicate {
    discriminator =:= '10000000'                     [ 8 ];
    length        =:= irregular(8)                   [ 8 ];
    value         =:=
      irregular(length.UVALUE*64+48) [ length.UVALUE * 64 + 48 ];
  }

Notes:

Incorrect Representation FN of IPv6 Route Options nomenclature
--VERIFIER NOTES--
This seems to be correct as this is referring to type 0 routing ext. headers. Nonetheless, this RFC has been obsoleted by RFC 6846.

Report New Errata



Search RFCs
Advanced Search
×