Dear Adnan, Tommaso, Thanks for considering my comments.
By the way, do I have it right that you haven't submitted the -01 yet ? (I can only see -00 on datatracker.) If yes, that would be fine. Just feel free to submit the -01 when ready. Thanks, Carles <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> On Thu, 15 Oct 2026 at 19:58, Adnan Rashid <[email protected]> wrote: > Dear Carles, > > Thank you for the valuable comments. > > I addressed all of them and attached the *diff* file for your and the > WG's reference. > > Regards, > > Adnan & Tommaso > > On Tue, Oct 13, 2026 at 1:31 PM Carles Gomez Montenegro < > [email protected]> wrote: > >> Hi Adnan, Tommaso, >> >> First of all, thanks for writing and submitting this draft. >> >> Please find below a few comments (as a WG participant). >> >> This draft describes a current issue and also proposes a solution. In my >> opinion, the draft is well motivated, and the solution is reasonable. While >> the draft is just a -00, the content appears to be already quite complete. >> >> Some more specific comments: >> >> - The draft mentions HC1 [RFC4944] in several places. I guess it probably >> does not hurt, but since HC1 was replaced by IPHC [RFC6282], I'm wondering >> to what extent there might still be any 6LoWPAN implementations using HC1 >> and not IPHC. >> >> - Section 3. "*ESC:* The 6LoWPAN Escape dispatch byte (0x7F), as defined >> in [RFC8025], used to introduce extended dispatch types." >> >> [Carles] RFC 4944 defined the ESC dispatch byte with value 0x7F. >> Subsequently, RFC 6282 replaced the 0x7F value by 0b01000000. >> >> - Section 4. Perhaps s/IPHC dispatch/IPHC format ? >> >> - Section 5. Perhaps not just "Any future 6LoWPAN compression scheme that >> elides the IPv6 PL field". For example, using SCHC might allow to elide the >> IPv6 PL field, at least in some cases, when there is a good match between >> the IPv6 PL field value and the corresponding field in a compression Rule. >> Note that SCHC (or any similar mechanism) does not necessarily rely on L2 >> PL to reconstruct the IPv6 PL field. >> >> Nits: >> >> - Section 7: s/PLmechanism/PL mechanism >> - Section 7.6: s/1bytes/1 byte >> >> I hope this helps! >> >> Cheers, >> >> Carles (as WG participant) >> >> >> >> >> >> >> >> >> On Sat, 22 Aug 2026 at 00:09, Adnan Rashid <[email protected]> >> wrote: >> >>> Hi 6Lo Working Group, >>> >>> We have posted a new individual draft: >>> draft-rashid-pecorella-6lo-lowpan-padding-length-00. >>> >>> Title: 6LoWPAN Payload Length Handling with L2 Padding >>> URL: >>> https://datatracker.ietf.org/doc/draft-rashid-pecorella-6lo-lowpan-padding-length/ >>> >>> Abstract: >>> 6LoWPAN compression schemes (HC1, IPHC, GHC) elide the IPv6 Payload >>> Length (PL) field, relying on the Layer 2 PL to reconstruct it at the >>> receiver. However, L2 technologies that enforce a minimum frame >>> size—such as Ethernet IEEE 802.3 with its 46-byte minimum payload—pad >>> short frames with zero bytes. This leads to incorrect IPv6 PL >>> reconstruction, packet corruption, and protocol failure. >>> >>> This document analyzes the issue and proposes a solution using an >>> Escape dispatch byte (ESC) or ESC Extension Type (EET) extended >>> dispatch mechanism to explicitly encode the IPv6 PL when L2 padding >>> may be present. >>> >>> We would appreciate any feedback, comments, or thoughts from the working >>> group. >>> >>> Best regards, >>> Adnan Rashid & Tommaso Pecorella >>> >>> _______________________________________________ >>> 6lo mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> > > -- > Regards, > > Adnan Rashid >
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
