> I think an updated, simplified fragmentation header to support the HC draft > would be the quickest way forward. Let's fix the main problem that started > this thread: Namely, that compressed headers spanning multiple RFC4944 > fragments presents huge complexities in re-assembly.
I couldn't agree more! I don't think we want to see 4944 completely re-whacked at this point. Let's fix the problem at hand. > > Sure, having a 6LoWPAN ACK may solve some issues, but how many use-cases does > it cover and is it worth all the extra work at this point. Couldn't ACKing be > added as an optional protocol some time in the future, for those that need it? Agreed. We're getting more and more 4944 compliant implementations and should be careful before we fragment our developers (pun intended). IIRC, this was discussed in Stockholm and while there was some interest in continuing the work, there was definitely no consensus to re-do the entire header and deprecate 4944. My $,02 (FWIW), ...Pete _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
