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