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
_______________________________________________
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
