Dear all The use case is when the data sync is not in the RPL domain or the packet has to fly outside the RPL domain. E.g., A PLC virtualized in a MEC. The root needs to uncompress the packet and forward. The draft is missing the uncompressed form.
All the best, Pascal From: Abdussalam Baryun <[email protected]> Sent: jeudi 23 mai 2019 13:31 To: Pascal Thubert (pthubert) <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [6lo] uncompressed form On Thu, May 23, 2019 at 7:54 AM Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> wrote: Dear all: I was rereading deadline and realized that the draft does not provide an umcompressed form. What of the packet flies beyond the RPL domain? I think the information should be useful there too. why useful? could you explain the use case? Also we always claimed that RFC8138 is an encoding and that we can always turn a packet to uncompressed and back. Deadline creates an exception to that rule, which changes RFC 8138 into a sub IP protocol as opposed to a compression. All in all, I think that an IPv6 header (e.g., a new option in a hop-by-hop header) should be provided, even if for now it appears to be for completeness only. What do others think? I need to know the use case. Best regards, AB
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
