RFC Errata
Found 12 records.
Status: Verified (3)
RFC 8824, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", June 2021
Source of RFC: lpwan (int)
Errata ID: 7389
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Verifier Name: Eric Vyncke
Date Verified: 2023-08-03
Section 3.1 says:
For example, the Uri-Path option is mandatory in the request, and it might not be present in the response.
It should say:
For example, the Uri-Path option can be used in the request, while it is not used in the response.
Notes:
The Uri-Path option is not mandatory in a CoAP request, and it is not supposed to be used in a CoAP response.
Errata ID: 7397
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Verifier Name: Eric Vyncke
Date Verified: 2023-08-03
Section 7.2 says:
These classes point out that the Outer option contains the OSCORE option and that the message is OSCORE protected; this option carries the information necessary to retrieve the Security Context.
It should say:
As per these classes, the Outer options comprise the OSCORE option, which indicates that the message is OSCORE protected and carries the information necessary to retrieve the Security Context.
Notes:
"Outer options" should be in the plural, to refer to the set of CoAP options left unencrypted. Such a set comprises also the OSCORE option, which is the actual indicator of the message being protected with OSCORE.
Errata ID: 7396
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Verifier Name: Eric Vyncke
Date Verified: 2023-08-03
Section 7.1 says:
Note that a client located in an Application Server sending a request to a server located in the Device may not be compressed through this Rule, since the MID might not start with 7 bits equal to 0.
It should say:
Note that, if a client is located in an Application Server and sends a request to a server located in the Device, then the request may not be compressed through this Rule, since the MID might not start with 7 bits equal to 0.
Notes:
In the old text, "compressed" seems referred to "client" rather than to "request" as intended.
Status: Reported (2)
RFC 8824, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", June 2021
Source of RFC: lpwan (int)
Errata ID: 8270
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Marco Tiloca
Date Reported: 2025-01-29
Section 7.3 says:
+---------------+---+--+--+----------------+-------+---------+======+ |CoAP OSCORE_kid|var|1 |Up| 0x636c69656e70 |MSB(52)|LSB |KKKK | +---------------+---+--+--+----------------+-------+---------+======+
It should say:
+---------------+---+--+--+----------------+-------+---------+======+ |CoAP OSCORE_kid|var|1 |Up| 0x636c69656e70 |MSB(44)|LSB |KKKK | +---------------+---+--+--+----------------+-------+---------+======+
Notes:
In Section 7.3, the example in Figure 12 considers the OSCORE kid 0x636c69656e74, with length 6 bytes (48 bits).
Also in Section 7.3, the Field Descriptor "CoAP OSCORE_kid" of the SCHC Compression Rule in Table 5 has the intent to send only the 4 least significant bits 0b0100, as reflected by "KKKK" in the column "Sent [bits]".
A successful matching with the Field Descriptor for compressing the corresponding field "CoAP OSCORE_kid" requires that the 44 (not 52) most significant bits produce a match, so that the remaining 4 least significant bits are sent.
Therefore, as per the corrected text above, the MO for the Field Descriptor about "CoAP OSCORE_kid" should be MSB(44).
Errata ID: 8271
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Marco Tiloca
Date Reported: 2025-01-29
Section 7.3 says:
Compressed message:
==================
0x001489458a9fc3686852f6c4 (12 bytes)
0x00 RuleID
1489 Compression Residue
458a9fc3686852f6c4 Padded payload
Compression Residue:
0b 0001 010 0100 0100 (15 bits -> 2 bytes with padding)
mid tkn piv kid
Payload
0xa2c54fe1b434297b62 (9 bytes)
Compressed message length: 12 bytes
It should say:
Compressed message:
==================
0x00148889458a9fc3686852f6c4 (13 bytes)
0x00 RuleID
148889 Compression Residue
458a9fc3686852f6c4 padded payload
Compression Residue:
0b 0001 010
mid tkn
0100 0100
piv (residue size and residue)
0100 0100
kid (residue size and residue)
(23 bits -> 3 bytes with padding)
Payload
0xa2c54fe1b434297b62 (9 bytes)
Compressed message length: 13 bytes
Notes:
In Section 7.3, the Rule in Table 5 is used to perform the OSCORE outer compression of the message shown in Figure 12, in order to produce the SCHC compressed message in Figure 14.
The residue shown in Figure 14 is not correct, with respect to what is sent on the wire for the fields of the OSCORE option identified as "CoAP OSCORE_piv" and "CoAP OSCORE_kid". Hence, the whole compressed message shown in Figure 14 is not correct.
Per Section 7.4.2 of RFC 8724:
> If the field is ... of variable length, then applying the CDA to compress this field may result in a value ... of variable size (e.g., value-sent or LSB). ..., the residue for that field is the bits that result from applying the CDA to the field, preceded with the size of the value.
In the considered Rule of Table 5, both "CoAP OSCORE_piv" and "CoAP OSCORE_kid" have FL=var. However, the old text for the SCHC-OSCORE Compressed GET Request of Figure 14 shows that the residue sent on the wire for the two fields is not prepended by the respective residue length (in bits).
Such a residue length has to be encoded as per Section 7.4.2 of RFC 8724, i.e.:
> The size (using the unit defined in the FL) is encoded on 4, 12, or 28 bits as follows:
> * If the size is between 0 and 14, it is encoded as a 4-bit unsigned integer.
> * Sizes between 15 and 254 are encoded as 0b1111 followed by the 8-bit unsigned integer.
> * Larger sizes are encoded as 0xfff followed by the 16-bit unsigned integer.
Status: Held for Document Update (3)
RFC 8824, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", June 2021
Source of RFC: lpwan (int)
Errata ID: 7623
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Ana Minaburo
Date Reported: 2023-08-31
Held for Document Update by: Éric Vyncke
Date Held: 2024-01-12
Section Section 7.1 says:
Table 3 Field FL FP DI TV MO CDA Sent [bits] CoAP Uri-Path var 1 Dw path equal 1 not-sent
It should say:
Table 3
Field FL FP DI TV MO CDA Sent [bits]
CoAP
Uri-Path var 1 Dw 1st. element equal not-sent
of the path
Notes:
A MO 'equal 1' has not been defined in the possibilities of SCHC. However, when this table was written and never updated, it was one option to say that we wanted to check only the first element. To comply with the RFC8724, the idea of only matching the first element of the path needs to be expressed in the corrected text way.
---- verifier note ---
Let's indeed fix this in draft-ietf-schc-8824-update
Errata ID: 7390
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Held for Document Update by: Éric Vyncke
Date Held: 2023-08-02
Section 5.1 says:
CoAP Content and Accept Options
It should say:
CoAP Option Content-Format and Accept Fields
Notes:
The new title of Section 5.1 uses the correct CoAP option name "Content-Format", and is consistent with the title of other sections.
Errata ID: 7393
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Held for Document Update by: Éric Vyncke
Date Held: 2023-08-02
Section 6.4 says:
Figure 4 shows the OSCORE option value encoding defined in Section 6.1 of [RFC8613], where the first byte specifies the content of the OSCORE options using flags.
It should say:
Figure 4 shows the OSCORE option value encoding defined in Section 6.1 of [RFC8613], where the first byte specifies the content of the OSCORE option using flags.
Notes:
The end of the sentence should still refer to a single OSCORE option, i.e., in the singular.
Status: Rejected (4)
RFC 8824, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", June 2021
Source of RFC: lpwan (int)
Errata ID: 7391
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Rejected by: Eric Vyncke
Date Rejected: 2023-08-03
Section 5.4 says:
The SCHC Rule description MAY define sending some field values by setting the TV to "not-sent", the MO to "ignore", and the CDA to "value-sent".
It should say:
The SCHC Rule description MAY define sending some field values by describing an empty TV, with the MO set to "ignore" and the CDA set to "value-sent".
Notes:
The new text indicates to use an empty TV, consistent with the intended CDA "value-sent".
--VERIFIER NOTES--
The WG/author wrote:
"As you can see 'not set' has been transformed into 'not-sent' during
the edition. And I prefer to use this terminology that corresponds to
the RFC8724."
in https://mailarchive.ietf.org/arch/msg/lp-wan/Vw5P6i0DysYqxClBj-gUjMEmqWY/
Errata ID: 7392
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Rejected by: Eric Vyncke
Date Rejected: 2023-08-03
Section 6.2 says:
Since the Observe Option MAY use a RST message to inform a server that the client does not require the Observe response, a specific SCHC Rule SHOULD exist to allow the message's compression with the RST type.
It should say:
Since the Observe extension MAY use a RST message to inform a server that the client does not require the Observe response, a specific SCHC Rule SHOULD exist to allow the message's compression with the RST type.
Notes:
A RST message is not used by the Observe option itself, but by a CoAP client when using Observe.
--VERIFIER NOTES--
The authors wrote:
"[Ana] as soon as I understand CoAP RFC7252 uses Options, and in the
RFC7641 Observe is also an Option, so I don't think that the change is
needed. Because Observe is not an extension."
in https://mailarchive.ietf.org/arch/msg/lp-wan/amZkZfocq1SQCpFPNJzoxn3TMsY/
Errata ID: 7394
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Rejected by: Eric Vyncke
Date Rejected: 2023-08-03
Section 7.1 says:
equal 1
It should say:
equal
Notes:
See the cell value of Table 3, last row, column "MO".
--VERIFIER NOTES--
Per the WG/author in https://mailarchive.ietf.org/arch/msg/lp-wan/ZVVEzAILvuGbudfpLhNp2xJuBDc/
Errata ID: 7395
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF
Reported By: Marco Tiloca
Date Reported: 2023-03-19
Rejected by: Eric Vyncke
Date Rejected: 2023-08-03
Section 7.1 says:
SCHC compression reduces the header, sending only the Type, a mapped code, and the least significant bits of the Message ID (9 bits in the example above).
It should say:
SCHC compression reduces the header, sending only a mapped Type (and only for uplink messages), a mapped code, and the least significant bits of the Message ID (9 bits in the example above).
Notes:
As per the discussed rule from Table 3, the Type is also omitted if it is CON for downlink messages.
--VERIFIER NOTES--
The author/WG wrote:
"In this case we are making a difference between the index of the
matching-list sent in Type and the mapped index used for Code that belongs
to the RFC7252 section 12.1 IANA values."
in https://mailarchive.ietf.org/arch/msg/lp-wan/s7EO2F4JUPHUyFLc3Qr-5RnwNZE/