Re: [6lo] SCHC HC over IEEE 802.15.4: comments

[Carles Gomez Montenegro <[e-mail]>]

Dear Georgios,

Many thanks, once again, for your comments!

Please find below my inline responses:


On Mon, 24 Jul 2023 at 22:32, Georgios PAPADOPOULOS
<[e-mail]> wrote:
>
> Dear Ana and Carles,
>
> Please find few more comments below:
>
> - Section 1:
> [GP] In the second paragraph, the following is written “On the other hand, an RFC 6282 compressed UDP header has a typical size of 4 bytes.”. We agree that RFC 6282 can compress the UDP header down to 2 bytes, isn’t it:
>
> Ports within 61616 to 61632 (4 bits).
> Length can be derived from IPv6 header Length information.
> Checksum can be elided, see subsection 4.3.2 in the RFC 6282.
> 1 byte of the Header.

[CG] The key point here is the *typical* size of 4 bytes. It is true
that the UDP checksum can be elided. However, the question would be:
how typical is that? As you point out, RFC 6282 (section 4.3.2) gives
the conditions under which the UDP checksum can be elided, and such
conditions comprise i) tunneling existing field protocols over UDP,
and ii) some form of integrity check in the UDP payload. I understand
that the latter may occur e.g. if UDP carries CoAP/DTLS or
CoAP/OSCORE. It is reasonable to assume that in such cases, indeed,
the UDP checksum can be elided. We will rewrite the related text in
our draft to incorporate your comment.

>
> - Subsection 3.1:
> [GP] If the idea is to introduce the third stack in Figure 2 (the one in the right), then one could say if you want to cover all options, then another one would be using SCHC compressing only CoAP, while 6LoWPAN for the UDP and IPv6, i.e., CoAP/SCHC HC/UDP/IPv6/6LoWPAN HC/6LoWPAN Frag/802.15.4

[CG] Well, the idea was not to actually cover all options. The
(so-called) "transition" option was added because there was an
explicit request for it. Is it the case for the option you suggest as
well?

> - Subsection 3.3.2:
> [GP] In this subsection the following is written “In this approach, a network node … “, in this case the “network node” is referring to a 6LN, 6LR, or to a 6LRB?

[CG] It refers to any node. It applies to a 6LBR, a 6LR or a host. We
will add some explanatory text in the sentence.

> - Subsection 3.3.2:
> [GP] A Topology-representation Figure would ease the description. For example, I believe a similar (or an extended) Figure 3 from RFC 9008 would do the job.

[CG] Agreed.

> - Subsection 3.3.3:
> [GP] I am not an English native speaker so I might be mistaken, but, in the following sentence, “An alternative approach where intermediate nodes neither have to store the Rules used by the endpoints for packet header compression/decompression, which also does not require IPv6-in-IPv6 encapsulation, non-storing mode RPL and RFC 8138 compression, is the Pointer-based Route-Over approach.”, the use of “neither” confuses me a lot since I am constantly looking for the "nor”.
> What about replacing it with simply “do not”?

[CG] From another non-native English speaker, your suggestion appears
to be safe. :-)

> — —
> I hope they (or at least some of them) make sense,

[CG] Thanks a lot for these (and for your earlier) comments! We plan
to incorporate your feedback in -03.

Cheers,

Carles (as one of the authors)


> Georgios

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Libre de virus.www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>