Hi Carles, No I did not submit it yet. Because I am waiting for other WG fellows comments.
😁 Regards, AR On Fri, Oct 16, 2026, 16:13 Carles Gomez Montenegro <[email protected]> wrote: > 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> > <#m_675989627263808185_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]
