[6lo] SCHC HC over IEEE 802.15.4: comments

[Georgios PAPADOPOULOS <[e-mail]>]

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.

- 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

- 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?

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

- 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”? 

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