# On updating RFC 8824

The following points have been considered while reviewing RFC 8824.

Some of them are eligible to file errata for RFC 8824.

Some of them can be addressed in the new Internet Draft for the LPWAN Working Group, possibly as related to an errata that is approved as "hold for document update".

All the headers below refer to section numbers of RFC 8824.

## Section 6

* Section 6 of RFC 8724 says: "The size of the RuleIDs is not specified in this document, as it is implementation-specific and can vary according to the LPWAN technology and the number of Rules, among other things. It is defined in Profiles."

RFC 8824 is not defining the size of RuleIDs either, although it consistently considers 1-byte RuleIDs in the examples in Section 7.

LT: All the rules are given as example and the rule ID size is just given as a byte for readability.

* I suppose that this is intentional, and RFC 8824 is not to be considered a "profile of SCHC". Is this correct?

LT: This is just examples of compression, it is not a mandatory way to compress CoAP. It will depends of the usage.

### Resolution

No actions.

## Section 3.1

* "For example, the Uri-Path option is mandatory in the request, and it might not be present in the response."

Two comments about this:

- The Uri-Path option is not supposed to be used in a response.

- The Uri-Path option is not mandatory in a request.

From Section 5.10.1 of RFC 7252:

"The steps for parsing URIs into options is defined in Section 6.4.
These steps result in zero or more Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options being included in a request ..."

From Section 6.4 of RFC 7252:

"The steps to parse a request's options from a string |url| are as follows. These steps either result in zero or more of the Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options being included in the request or they fail."

That is, you may indeed have a request including no Uri-Path options, e.g., if the target URI is coap://foo or coap://foo/

Therefore, RFC 8824 should actually say something like:

"For example, the Uri-Path option can be used in the request, while it is not used in the response."

This can be filed as a technical errata to RFC 8824.

LT: Agree, I think i may come from a confusion with location-path, RFC8824 says that they must be sent as residue, may be it is not so true :(
in fact, for instance LwM2M send /rd/value and /rd can be not-send and /value is value-sent.

### Resolution

File a technical errata to RFC 8824; no action in the new draft.

## Section 5.4 // NEW

* The title of the section is "CoAP Content and Accept Options", while it should be "CoAP Option Content-Format and Accept Fields", also for consistency with other section titles.

### Resolution

File an editorial errata to RFC 8824; no action in the new draft.

## Section 5.4

* "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"."

This should actually say something like:

"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"."

This can be filed as an editorial errata to RFC 8824.

LT: correct

### Resolution

Find an editorial errata to RFC 8824.

The new draft includes a revised version of Section 5.4 "CoAP Option Size1, Size2, Proxy-URI, and Proxy-Scheme Fields", with the fixed text. This would address the errata if approved as "hold for document update".

## Section 6.2

* "Since the Observe Option MAY use a RST message ..."

This reads a bit strange. Perhaps what is intended is: "Since the Observe extension MAY use a RST message ..."

This can be filed as an editorial errata to RFC 8824.

LT: yes

### Resolution

File an editorial errata to RFC 8824; no action in the new draft.

## Section 6.4 // NEW

* "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."

This should rather be:

"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."

### Resolution

File an editorial errata to RFC 8824; no action in the new draft.

## Section 6.4

* "The three most significant bits of this byte are reserved and always set to 0."

This is not the case anymore. In particular:

- bit 2 is now used to signal that the message is protected with the group mode of Group OSCORE (see draft-ietf-core-oscore-groupcomm);

- bit 1 is going to be redefined as "Unassigned" (see draft-ietf-core-oscore-key-update);

- bit 0 is going to be defined for extending the flag bits with an additional byte of flag bits (see draft-ietf-core-oscore-key-update).

We may use our new draft for updating RFC 8824 also in this respect.

* "The SCHC Rule splits the OSCORE option into four Field Descriptors in order to compress them..."

Thinking of the ongoing work on the KUDOS key update protocol defined in draft-ietf-core-oscore-key-update, a SCHC rule should now also consider the following fields:

i) The CoAP OSCORE_flags in a broader sense, since it might be extended with additional bytes than the first one.

If I understand correctly, that should be just fine the way it is already. That is, it seems that extensibility of the OSCORE flag byte has already been taken into account by RFC 8824. Is this correct?

ii) Any other parts of the OSCORE option than the original ones from RFC 8613 and the extended OSCORE_flags.

This includes, e.g., the 'x' and 'nonce' fields introduced with KUDOS in draft-ietf-core-oscore-key-update.

We may use our new draft for updating RFC 8824 also in this respect.

In particular, 'nonce' should just be sent as is. So it should be about an empty TV, the MO set to "ignore" and the CDA set to "value-sent".

Instead, assuming that the two peers have agreed on running KUDOS always with the same nonce size and with the same features (e.g., without preserving ongoing CoAP observations and in FS mode to preserve forward secrecy), then the 'x' byte may not be sent. That is, TV is set to the pre-known value of 'x', the MO is set to "equal" and the CDA is set to "not-sent". If different combinations of nonce size and features are possible to consider for the two peers running KUDOS, then either they define multiple rules to cover the different possible combinations, or they send the 'x' byte without compression.

LT: yes, it is also important to look at the data model, may be in the new draft provide augmentation of the YANG DM to cover new options if the definition differs from RFC 8824. The values are not so critical since they are stored in the rule.

### Resolution

The new draft includes a revised version of Section 6.4 "OSCORE".

## Section 7.1

* Table 3, last row, column "MO".

The cell value says "equal 1". Shouldn't it say "equal" instead?

If the above is correct, this can be filed as an editorial errata to RFC 8824.

LT: yes, don't know why there is a 1 here.

### Resolution

File an editorial errata to RFC 8824; no action in the new draft.

## Section 7.1

* "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)."

Actually, as per the discussed rule from Table 3, the Type is also omitted if it is CON for downlink messages. So the sentence should say something like:

"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)."

If this is correct, this can be filed as an editorial errata to RFC 8824.

LT: yes

### Resolution

File an editorial errata to RFC 8824; no action in the new draft.

## Section 7.1

* "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 ..."

This reads strange, since "compressed" seems referred to "client" rather than to "request". It should probably 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 ..."

This can be filed as an editorial errata to RFC 8824.

LT: agree

### Resolution

File an editorial errata to RFC 8824; no action in the new draft.

## Section 7.2

* "These classes point out that the Outer option contains the OSCORE option ..."

This should probably say: "These classes point out that the Outer options comprise the OSCORE option".

This can be filed as an editorial errata to RFC 8824.

### Resolution

File an editorial errata to RFC 8824; no action in the new draft.

## Section 7.2

* There seems to be missing clarifications about how the 0xFF marker is handled.

That is, according to the examples in Section 7.3, the 0xFF marker is removed by the SCHC compression. However, the considered compression rules are (intentionally) not including a field descriptor about the 0xFF marker.

LT: I don't see where is the problem, in the figure the 0xFF marker is on uncompressed packet, not in compress ones.

MT: Right, the examples are correct and consistent. However, it is not said anywhere that the payload marker has to be removed as the result of the compression.

This looks more like an "implicit field descriptor" for every CoAP-related rule, that practically always treats the 0xFF marker as a "not-sent" field. This is the case irrespective of OSCORE being used or not.

LT: I agree, we changed our point of view for the marker during the writing of the draft, before it was viewed as a part of the header, but since the header is clearly specified by the rule, we don't need it. That's why SCHC works on list of fields and not directly on the packet header bytes.

If this is the correct interpretation, then it's worth clarifying it. Otherwise, the compression rules would also have to include a field descriptor about the 0xFF marker to achieve the intended result consistently shown in the examples.

The current text in RFC 8824 may make the reader wonder why the examples show that the 0xFF marker is not present anymore after SCHC compression, while at the same time there is no field descriptor in the considered rules, and no consideration/discussion about it either.

If the above is correct, this can be filed as a technical errata to RFC 8824.

LT: yes

### Resolution

On a second thought, it is better to NOT file an errata for RFC 8824.

Instead, we can provide an explanation in the new draft with a dedicated section.
* Following the compression, the payload (if any) is always preserved while the 0xFF marker (if any) is always removed. The same principle applies when performing both the inner and outer compression for OSCORE.
* For incoming message, the 0xFF marker will have to be prepended to the payload (if any) after having completed a decompression.

---

## List of errata to file for RFC 8824

### Errata 1 (technical)

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."

Comments:

* The Uri-Path option is not supposed to be used in a CoAP response.

* The Uri-Path option is not mandatory in a CoAP request.

### Errata 2 (editorial)

The title of Section 5.4 is:

"CoAP Content and Accept Options"

It should be:

"CoAP Option Content-Format and Accept Fields"

Comments:

The change would be consistent with the CoAP option name and other section titles in RFC 8824.

### Errata 3 (editorial)

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"."

### Errata 4 (editorial)

Section 6.2 says:

"Since the Observe Option MAY use a RST message ..."

It should say:

"Since the Observe extension MAY use a RST message ..."

### Errata 5 (editorial)

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."

### Errata 6 (editorial)

In Section 7.1, Table 3, last row, column "MO", the cell value says:

"equal 1"

It should say:

"equal"

### Errata 7 (editorial)

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)."

Comments:

As per the discussed rule from Table 3, the Type is also omitted if it is CON for downlink messages.

### Errata 8 (editorial)

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 ..."

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 ..."

Comments:

In the old text, "compressed" seems referred to "client" rather than to "request" as intended to.

### Errata 9 (editorial)

Section 7.2 says:

"These classes point out that the Outer option contains the OSCORE option ..."

it shoudl say:

"These classes point out that the Outer options comprise the OSCORE option".