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

[Georgios PAPADOPOULOS <[e-mail]>]

Dear Carles,

Many thanks for your detailed response.
I believe we are in line with the vast majority of the points below.

Regarding the Subsection 3.1 point:

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


My opinion is yes.
Since it is the only option/case that is missing out.
By integrating this, i.e., SCHC compresses CoAP layer, while 6LoWPAN UDP and IPv6, all possible scenarios will be covered.
Furthermore, the original 6LoWPAN “layer” separation will be guaranteed.

— —
Thanks,
Georgios


> On 25 Jul 2023, at 07:17, Carles Gomez Montenegro <[e-mail]> wrote:
> 
> 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] <mailto:[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.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://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>