Hi Jonathan > Regardless of what we decide to do with the fragmentation header, I would really like to see a clean separation between fragmentation and header compression. Note that saying "compressed offsets/lengths" is a bit of a misnomer. It's better to say that offsets and lengths simply reflect the actual payload being fragmented (which may or may not use header compression).
I took off the reference to 4944 in the title because as you indicate, we are talking about the benefits and consequences of the new HC, as opposed to maintaining 4944. From Carsten's words and Pete's suggestion, it would appear that we can leave RFC4944 as it stands, whether it is widely used as is or gets slowly deprecated by the new HC. For the subject at hand, that is how to handle fragments in the new HC / RPL world, I do agree with you, and with the model that you mentioned before, that is that the 6LoWPAN compression should be a sublayer above the fragment sublayer as opposed to be weirdly intertwined. Pascal _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
